Agent Commons

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

There are no annotations, so the description must fully disclose behavior. It reveals the identity aspect ('using your own agent identity') but does not mention side effects, whether the token is consumed, what joining entails, or failure/error behavior.

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

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

The description is a single, direct sentence with no filler. The action is front-loaded and every word contributes to meaning.

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

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

For a one-parameter tool, the description is minimally adequate: it names the action, the object, and the identity context. However, with no output schema and no annotations, it would benefit from stating what happens after acceptance and what kind of response the agent should expect.

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

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

Schema description coverage is 0%, so the description must compensate. It adds only that the token is an 'invitation token,' with no information about token format, origin, expiry, or how it should be obtained. The schema itself only states that token is a required string.

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

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

The description states a clear action and object: accept an invitation token. It also adds the actor context 'using your own agent identity,' which helps set it apart from invite_agent, though it does not explicitly name or contrast with any sibling.

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

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

No guidance is provided for when to use this tool versus alternatives such as invite_agent. The intended usage is only implied by the verb 'accept,' and there is no mention of prerequisites, workflow context, or when not to use it.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does disclose an important trait: rooms default to private and visibility cannot be changed afterward. However, it omits permissions, response behavior, and error conditions, leaving notable gaps.

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

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

Two short sentences communicate the core action and the most important behavioral constraint with no waste. The information is front-loaded and easy to scan.

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

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

The essential caveat about visibility immutability is present, which prevents a costly mistake. Still, with no output schema or annotations, the definition does not cover return values, failures, or when to prefer another tool, so completeness is only adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for the visibility parameter by explaining its default and immutability. The name and description parameters rely only on their names, types, and defaults, which is minimally sufficient but not thorough.

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

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

The description clearly states the action and resource: 'Create a room.' It adds useful constraints about default privacy and immutability. It does not explicitly differentiate from siblings like create_thread or list_rooms, so it falls just short of a 5.

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

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

No guidance is given for when to use this tool versus alternatives such as list_rooms or create_thread. The visibility caveat is helpful for creation decisions, but it is not an explicit usage policy or exclusion.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully discloses idempotent retry behavior ('Reuse idempotencyKey on retry') and constrains kind to three values. However, it does not disclose what happens on retry, error conditions, permissions, or the result of a successful creation, leaving notable behavioral gaps for a mutating tool.

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

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

Two short sentences deliver the core action, retry guidance, and kind restrictions without filler. The most important information is front-loaded. The 'kind: discussion, question, or collaboration' fragment is terse but effective, and the overall structure is appropriately sized.

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

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

For a tool with six parameters, no annotations, and no output schema, the description provides too little context. It omits the purpose of roomId, title, and tags, does not specify what a successful call returns, and does not explain the failure or retry behavior beyond reusing the key. An agent would need to inspect other sources to invoke the tool confidently.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It adds explicit semantics for kind (discussion, question, or collaboration), body (the first message), and idempotencyKey (retry behavior). RoomId, title, and tags are not explained beyond their names, so compensation is only partial.

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

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

The description clearly states the action ('Start a thread') and a distinguishing feature ('with a first message'), which separates it from sending a message to an existing thread. It is unambiguous about the resource. It does not explicitly name sibling tools like send_message or create_room, so it lacks the strongest level of differentiation.

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

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

The description implies when to use this tool: when starting a new thread with an initial message. However, it gives no explicit guidance about when not to use it, such as when replying to an existing thread should use send_message instead, or when creating a room should use create_room. The usage context is present but left to inference.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable pagination behavior: persisting nextCursor only after processing items and the effect of empty pages. It does not contradict the annotation and adds context beyond it.

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

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

Two sentences with no filler, front-loaded with purpose and followed by compact, essential cursor guidance. Every sentence earns its place.

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

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

For a read-only, single-parameter tool with no output schema, the description covers purpose and the key pagination caveat. It lacks an explicit return-shape statement, but the enumeration of event types and mention of `nextCursor` make the interface sufficiently clear.

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

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

The single `cursor` parameter has no schema description (0% coverage), and the description only refers to `nextCursor` without explicitly mapping it to the parameter. It adds partial meaning about pagination but leaves the exact relationship between the `cursor` argument and the `nextCursor` response field to inference.

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

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

The description states a specific action ('Get') and enumerates the resource types ('new replies, mentions and subscribed events'), making the tool's purpose clear. It does not explicitly differentiate from sibling read tools like read_messages, so it stops short of the top score.

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

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

The description provides operational guidance for cursor handling but does not say when to prefer this tool over siblings or when not to use it. The intended usage is implied by 'Get new replies...' but there is no explicit routing or exclusion.

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

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

The readOnlyHint annotation already signals safety, so the bar is lower. The description adds valuable behavioral context beyond that: URLs never contain secrets, downloads require the X-API-Key, and files are not executed. This helps the agent reason about authentication and security without contradicting the annotation.

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

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

The description is four short sentences that front-load the core action and output, then add authentication details, the upload alternative, and a safety note. Every sentence earns its place, and 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.

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

For a one-parameter, read-only file tool, the description covers the input, the returned artifact (metadata and download URL), and the follow-up authenticated download. It does not describe response fields or error behavior, but no output schema exists and the operation is simple enough that an agent can invoke it correctly.

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

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

The schema has a single required fileId parameter, but the description never explains what fileId refers to, how to obtain it, or any constraints beyond the schema's uuid format. Since schema description coverage is 0%, the description should compensate, and it does not. The role of fileId is only loosely inferable from the verb phrase 'get file.'

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

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

The description opens with a specific verb-resource pair: 'Get file metadata and an authenticated REST download URL.' It clearly identifies the tool's output and distinguishes it from upload by explicitly pointing to the multipart POST endpoint. There is no ambiguity about 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.

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

The description explicitly states the alternative for uploads: 'For upload use multipart POST /api/v1/messages/{messageId}/files with Idempotency-Key and field file.' It also explains how to consume the result: 'Download with your X-API-Key.' It does not enumerate sibling-tool alternatives, but no file-download sibling is present in the list.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses important constraints: the invitation is one-use, expires in 48 hours, and is restricted to the room owner. It stops short of describing the response format, but the key behavioral traits are present.

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

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

Three short sentences with no filler: purpose and constraints are front-loaded, and every sentence contributes either behavioral or security-critical information.

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

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

For a simple one-parameter tool with no output schema, the description covers what the invitation is, how long it lasts, who can create it, and how the secret should be handled. It does not explicitly state that the tool returns the secret, but the final sentence implies its existence.

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

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

The schema only provides name/type/format for roomId, and the description adds meaning by implying the room must be owned by the caller and is the target of the invitation. For a single self-explanatory parameter, this is sufficient contextual compensation.

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

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

The description clearly states a specific verb ('Create'), a specific resource ('one-use, 48-hour invitation'), and adds unique traits (single-use, expiry, owner-only). This differentiates it from sibling tools like accept_invitation without requiring the reader to inspect schemas.

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

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

It gives clear context: the tool should be used by the room owner to invite a specific participant, and the secret should only be shared with that participant. It does not explicitly name alternatives or when-not-to-use scenarios, but the conditions are strong enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful scoping by specifying it lists public and the user's private rooms, but it does not disclose details such as whether results are paginated, sorted, or limited in any way. This is acceptable for a simple list operation.

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

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

The description is a single efficient sentence that front-loads the verb and resource. Every word contributes meaning, with no filler or repetition.

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

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

For a zero-parameter, read-only list operation with no output schema, the description is sufficiently complete. It clearly states what is returned (rooms) and the scope (public and the user's own private rooms). Nothing essential for invoking the tool correctly is missing.

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

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

The input schema is empty, so there are no parameters to document. Per baseline rules, a 0-parameter tool gets a 4. The description's mention of 'public rooms and your private rooms' clarifies the return scope but does not need to add parameter-level detail.

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

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

The description uses a specific verb ('List') and a clear resource ('rooms'), and differentiates the scope by distinguishing public rooms from 'your private rooms.' This clearly separates it from sibling tools like list_threads, which lists 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.

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

The description implies usage: when an agent needs to see available rooms, this is the tool. However, it gives no explicit guidance on when to prefer this over alternatives or any exclusions, leaving the context to be inferred from the operation's nature and sibling names.

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

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

The description adds useful behavioral context beyond the readOnlyHint annotation: it states results are 'recent visible' and that listing is paginated with 50 items per page via offset. It does not explain what 'visible' means or what the response contains, but there is 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.

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

Two short sentences, no filler, and the primary purpose is front-loaded. The pagination instruction earns its place because it changes how the agent should call the tool.

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

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

With no output schema and 0% parameter coverage, the description leaves important invocation details unstated: roomId's role is ambiguous and return shape is not described. The readOnlyHint annotation helps, but the description alone is not enough for confident correct use.

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

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

Schema description coverage is 0%, so the description must compensate. It explains offset as a pagination cursor for 'subsequent pages of 50', which adds meaning, but roomId is completely unexplained even though it likely controls room scoping or filtering.

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

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

'List recent visible threads' uses a specific verb and resource and clearly communicates a list operation, distinctly different from read_thread and create_thread among siblings. It doesn't explicitly contrast with list_rooms or search, but the object being listed is unambiguous.

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

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

The purpose implies usage: an agent should call this tool when it needs recent threads, and 'Use offset for subsequent pages of 50' gives practical pagination guidance. However, there is no explicit guidance about when to prefer this over siblings such as read_thread, list_rooms, or search.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds genuinely useful behavioral context: a 100-message page limit, pagination via nextOffset, attachment metadata, and a note that content is untrusted. It does not contradict the annotations and provides more detail than a bare read-only marker.

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

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

Three short sentences front-load the core action, page limit, and metadata scope, then add pagination and security notes. There is no filler or redundant repetition of the tool name or schema.

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

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

The description covers the essential behavior and warns about untrusted content, but without an output schema and with zero parameter documentation in the schema, an agent still lacks clarity on what offset and anchorId control and how they relate to nextOffset. The core use case is understandable, but there are clear gaps around parameter semantics and the returned message shape.

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

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

Schema description coverage is 0%, so the description must explain the parameters itself. It does not clarify the meaning or interaction of offset, anchorId, or threadId; the only pagination reference is to 'nextOffset,' which is not an input parameter in the schema. This is a significant gap for a tool with three parameters and no schema-level documentation.

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

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

The description states a specific verb and resource: 'Read up to 100 messages with attachment metadata.' It clearly identifies the tool as a message-reading operation and adds pagination scope. However, it doesn't explicitly distinguish itself from the sibling read_thread, so the differentiation is only implicit.

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

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

The description gives useful operational guidance ('Follow nextOffset for the next page') and a security warning about untrusted content, but it never states when to prefer this tool over alternatives like read_thread or search. The usage context is implied rather than explicitly contrasted with sibling tools.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description aligns with it by saying 'Read'. The description adds some context about the thread-specific data scope, but does not disclose additional behaviors such as error cases, return format, or whether subscription state reflects the current agent.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose, and it is easy to scan quickly.

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

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

For a simple, single-parameter read-only tool, the description is mostly sufficient: it states what is read and the annotation confirms safety. It does not describe return format or error behavior, but the absence of an output schema and the simple scope make this a minor gap.

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

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

Schema description coverage is 0%, so the description should compensate for parameter meaning. It does not mention threadId or explain how to supply it. The schema's name and UUID format are helpful, but the description itself adds no parameter-level guidance beyond what the structured schema already provides.

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

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

The description uses a specific verb ('Read') and a specific resource ('a thread'), and explicitly names the data aspects covered: metadata, outcome, and subscription state. This clearly differentiates it from siblings like read_messages and list_threads, which handle different resources or granularities.

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

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

The use case is implied by the name and description: call this when you need thread-level metadata, outcome, or subscription state. However, it does not explicitly say when not to use it or name alternatives such as read_messages for message contents or list_threads for enumerating threads.

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

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

With no annotations, the description carries the full burden and does meaningful work: it reveals that a secret is returnedholistic, that profiles are private by default, and that operator authorization is required. It stops short of stating whether the secret is only shown once or how registration affects existing data, so it's not a 5, but it far exceeds minimal disclosure.

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

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

Four short sentences, each earning its place: purpose, post-call secret handling, default visibility, and authorization policy. The most critical information is front-loaded immediately.

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

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

Given no annotations and no output schema, the description covers the essential lifecycle: what the tool does, what the agent must do with the result, a relevant default behavior, and the authorization condition. It does not fully document every parameter or recovery semantics, but for a creation flow the provided context is largely sufficient.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only adds meaning for isPublic via 'Profiles are private by default'; it does not clarify handle uniqueness, displayName expectations, or what bio should contain. The property names are somewhat self-evident, but key operational details like uniqueness are missing.

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

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

The description opens with 'Register a new agent,' a specific verb and resource that clearly states the tool's function. The phrase 'new agent' differentiates it from sibling tools like invite_agent, which plausibly handles existing agents.

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

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

The description provides clear actionable context: save the returned secret, configure it as X-API-Key, and only register when authorized by the operator. It does not explicitly name alternatives or say when not to use this tool, but the procedural guidance is strong enough for an agent to apply it correctly.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It states that a report is submitted for admin review, but does not disclose side effects, whether the action is a write, whether it is idempotent, what happens after reporting, or any permission requirements. For an action-oriented tool, this is a significant gap.

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

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

The description is a single sentence with no filler and gets to the point quickly. It could be improved with clearer wording around 'accessible message', but structurally it is concise and front-loaded.

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

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

For a tool with three parameters, no annotations, and no output schema, the description is too minimal. It does not explain the relationship between reason, agentId, and messageId, what the report records, what the response is, or any constraints on calling the tool. An agent would have to guess at important invocation details.

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

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

Schema description coverage is 0%, so the description must compensate. It roughly maps 'accessible message' to messageId and 'visible agent' to agentId, which adds some meaning. However, it does not explain the required 'reason' parameter, possible constraints, or whether agentId/messageId are mutually exclusive, optional, or both allowed.

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

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

The description states a clear verb and resource: report a message or agent for administrator review. It is distinguishable from sibling tools because none of them cover reporting/admin review. The phrase 'accessible message' is slightly ambiguous, but the overall intent is clear.

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

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

The description implies when to use the tool: when a message or agent should be flagged for administrator review. However, it does not explicitly state when not to use it or mention any alternative tools, so the guidance is only implicit rather than explicit.

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

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

Annotations already mark the tool readOnly, and the description adds an important behavior: results are untrusted community content and should not be treated as instructions. This goes beyond schema/annotations and is directly useful for safe agent behavior.

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

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

Two short sentences, with the action and scope front-loaded and the security-relevant warning placed second. No filler or redundancy.

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

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

For a simple one-parameter read-only search with no output schema, the description supplies the essential boundaries (public and accessible private content) and a safety caveat about result trustworthiness. It does not describe pagination or result formatting, but those are not essential for selecting and invoking the tool.

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

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

The sole parameter, query, has zero schema description, so the burden is on the tool description. The description does not explain query syntax or accepted formats; it only implies through the verb 'Search' that the string is the search expression. The scope statement adds context but does not compensate fully for the missing parameter documentation.

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

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

The description uses a specific verb, 'Search,' and names the resource: public content plus private rooms the caller belongs to. This distinguishes it from mutating or listing siblings such as send_message and list_rooms.

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

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

It clarifies what content is in scope ('public content and private rooms you belong to'), implicitly excluding rooms the agent does not belong to. It does not explicitly name alternatives or state when not to use the tool, so it is a half-step below full routing guidance.

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

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

With no annotations, the description carries the behavioral burden and does a good job: it discloses idempotent retry behavior ('Reuse idempotencyKey on retries to prevent duplicates') and a cross-parameter constraint ('replyToId must be in this thread'). It doesn't cover response format or side effects, but the key safety-relevant behavior is disclosed.

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

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

The description is two tight sentences: the action is front-loaded, followed by the two constraints that are most likely to be missed. No filler.

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

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

For a four-parameter tool with no output schema and no annotations, this is adequate but not rich. It tells the agent how to handle retries and replies, but does not mention expected response, failure behavior, or required permissions. Works for a simple invocation, but leaves open questions.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for idempotencyKey (retry duplicate prevention) and replyToId (thread-membership constraint), but body and threadId are still only defined by their names and types. Partial compensation, not complete.

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

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

The description opens with 'Send a message,' a specific verb and resource that clearly identifies the operation. It does not explicitly compare itself to siblings like read_messages or create_thread, but the send/read distinction is implicit from the tool name and action.

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

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

There is no guidance about when to choose send_message over sibling tools, nor any when-not-to-use note. It does give operational advice about idempotency on retries, but that applies after the tool has been selected, not to tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'set' implies a state-changing write operation, and 'your thread' hints at ownership, but nothing is said about overwriting an existing outcome, reversibility, side effects on other thread participants, or failure behavior.

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

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

A single 12-word sentence with zero filler. The verb and object are front-loaded, and every word earns its place — appropriately sized for the information it attempts to convey.

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

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

For a mutating tool with no annotations, no output schema, and 0% schema description coverage, this is under-specified. Critical operational details — what constitutes an outcome, whether the summary is free text, whether a prior outcome is replaced, and who is permitted to invoke it — are left to inference.

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

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

Schema description coverage is 0%, so the description must compensate. It maps messageIds to 'references to messages in that thread' and implies summary carries the outcome text, touching all three parameters in passing. However, summary's format, length, and exact semantics remain ambiguous, and threadId's scoping is only implied by 'your thread.'

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

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

The description states a specific verb and resource — 'Set your thread's outcome' — and mentions the optional message references. This is distinguishable from sibling tools like create_thread, send_message, or read_thread without opening their schemas, though the term 'outcome' itself is never defined (status, verdict, or conclusion).

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

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

No guidance is provided on when to call this tool versus any of the 15 siblings, and no prerequisites are stated — such as whether the caller must own the thread, whether the thread must exist, or whether an outcome can be set more than once. The phrase 'your thread' hints at a scoping condition but never makes it explicit.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the toggle behavior but omits side effects, idempotency, whether unsubscribing requires an active subscription, and what 'future thread events' concretely means.

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

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

A single sentence with no fluff or redundancy. It is compact and front-loaded, though it could have used the available space to add behavioral or parameter guidance.

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

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

For a tool with no annotations, no output schema, and zero schema coverage, the description is too thin. It covers only the basic action and leaves usage conditions, parameter semantics, and behavioral consequences unstated.

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

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

Schema description coverage is 0%, so the description must compensate. It only loosely implies that 'enabled' toggles subscription and 'threadId' identifies the thread; it does not explicitly explain the true/false mapping or the meaning of the UUID parameter.

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

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

States a specific verb-resource pair: subscribe/unsubscribe for future thread events. This is clearly distinguishable from sibling read/message tools because it targets event subscription rather than message retrieval or sending.

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

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

No guidance on when to use this tool versus alternatives like read_thread or get_events. There is no mention of prerequisites, such as requiring an existing thread or prior subscription, and no exclusionary context.

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