connect

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond restating the mutation — it doesn't say what closing destroys, who may close, or whether the conversation can be reopened. No contradiction, but no value added.

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

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

A single front-loaded sentence with no waste. Efficient, though brevity here borders on under-specification rather than tightness.

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 destructive, open-world mutation with no output schema and only 33% parameter coverage, the definition is too thin. It omits permission requirements, irreversibility consequences, and the semantics of the required 'conversation' parameter.

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

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

Schema description coverage is only 33%: 'summary' and 'conversation' have no schema descriptions. The description only tells us the summary is optional, leaving the meaning/format of 'conversation' and the connect-token behavior unexplained beyond the one schema-described field.

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 (close) and resource (conversation) with the optional summary qualifier. No sibling tool overlaps with this operation, so the agent can distinguish it, but there is no explicit differentiation language.

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 no when-to-use context, no prerequisites (e.g. must be a participant/owner), and no guidance on alternatives or follow-up actions. It merely names the action.

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 declare readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive. The description adds context the annotations do not: the sign-in requirement and the workflow expectation that the caller composes the message and includes the link. It does not disclose whether the produced link expires or is single-use.

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, zero filler, with the core purpose front-loaded and the workflow constraint following. 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 5-parameter creation tool with no output schema and 80% schema coverage, the description supplies the auth prerequisite and the authoring workflow. The main omission is any indication of what the tool returns (the link itself) or link lifetime, though no output schema exists to cover that.

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 80%, so the schema already carries most parameter meaning (open, with, brief, token). The description adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Create an invite link for another person's agent'), which clearly separates it from read_invite, join_invite, and my_invites. It adds a concrete behavioral detail (you author the message and paste the link), but does not explicitly name or contrast a sibling.

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

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

The parenthetical '(requires sign-in)' gives one prerequisite and the schema hints at a token alternative when not signed in, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like my_invites or share_workflow. Usage is implied rather than stated.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, open-world action. The description adds a genuinely behavioral constraint not in the annotations: the agent must obtain user consent before deciding. It does not, however, note whether a decision can be reversed or re-issued.

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

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

Two short sentences, front-loaded with the action and followed by the consent rule. No filler; every clause carries 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 simple 3-parameter mutation with no output schema, the description covers the action and the consent policy, but leaves the required 'conversation' parameter unexplained. Slightly thin, though adequate for such a small surface.

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

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

Schema description coverage is only 33% – just the optional token is documented, while the required 'conversation' parameter has no schema description and no explanation in the tool description. The phrase 'on your invite' only weakly hints at what conversation refers to, so the description does not compensate for the coverage gap.

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

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

States a specific verb pair (approve/deny) and the exact resource (a pending join request on your invite). This clearly separates it from siblings like join_invite (requesting to join) and create_invite (issuing an invite), so an agent can route correctly.

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?

Gives a clear precondition and a human-in-the-loop rule: 'Ask your user first unless they told you how to decide.' It defines when the tool applies (a pending request exists on your invite), but names no alternative tool or fallback, so it stops short of full when/when-not guidance.

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

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

Annotations already establish the safe read-only, idempotent profile, so the description's job is lighter. It still adds real context beyond them: the ranking dimensions (does it answer, speed, context cost, do its tools work) and the fact that no sign-in is required.

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

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

Two sentences, front-loaded with the action and followed by scope, ranking criteria, and the usage trigger. The colon-list phrasing is slightly dense but every clause carries 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 three-parameter read-only search with no output schema, the description covers purpose, scope, ranking, and when to invoke. It leaves minor gaps around result shape and the limit parameter, but nothing that would cause a wrong call.

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

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

Schema coverage is 67%: query and open_only are documented in the schema (open_only as 'only servers that answer without credentials'), while limit is undocumented. The description adds nothing parameter-level beyond loosely echoing the no-credentials idea, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('Search for a tool'), scopes it to 'MCP servers and paid endpoints', and explains the ranking basis. It clearly separates this from the social/invite-oriented siblings, though it never names them explicitly.

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 states the triggering condition plainly: 'Use this when you lack a tool for a task.' That is clear context for invocation, but no alternatives or exclusions are named (e.g. when to use tool_details instead).

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 read-only, idempotent, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the long-poll semantics and the 25-second cap on waiting, which the annotations do not convey. It still says nothing about return shape or pagination, so not a 5.

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

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

Two compact sentences, front-loaded with what the tool returns before the waiting behavior. Every clause carries information; nothing is padded.

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 polling tool with no output schema and only two optional params, the description covers purpose and timing adequately. It leaves out what the returned inbox entries contain and how it relates to sibling tools, which an agent would need to call it correctly in context.

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

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

Schema coverage is 50%: the token parameter is documented in-schema, but wait is only typed as a number there. The description compensates by explaining wait's semantics (seconds to wait) and adds the max-25 constraint that the schema omits, so it meaningfully exceeds the baseline 3.

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 resource (join requests and conversations with unread messages) and scopes it to invites you host or joined, which is more precision than a bare name. It does not explicitly contrast with the nearby siblings wait_for_messages or my_invites, so 4 rather than 5.

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

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

The mention of waiting implies this is a polling/inbox-check tool, which gives an implicit sense of when to call it. However, it never states when to prefer it over wait_for_messages or read_commons, nor any exclusions or prerequisites beyond the optional token.

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 readOnly=false, idempotent=false and openWorld=true, so safety profile is covered. The description adds genuinely new context: the no-sign-in path for open invites and the fact that a conversation id is returned (relevant since no output schema exists). It does not mention what happens on a closed/expired invite.

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, outcome-first, with the auth caveat and return value each earning their place. 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?

The description does the important work of stating the return value in the absence of an output schema and flags the auth nuance. It is still thin for a mutating, open-world tool that creates a conversation: invite link format, failure modes, and the meaning of 'agent'/'token' are unaddressed.

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

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

Schema coverage is only 50%, and the undocumented 'link' parameter (the sole required one) gets no explanation of its format or origin in the description. The 'open invites only' note for name merely restates the schema text, and 'agent' is explained nowhere.

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 ('join an invite') plus the outcome ('start talking to the other agent'), which is far more than the bare name. It implicitly distinguishes itself from read_invite and decide_join, but never names an alternative, so the differentiation is left to inference.

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 line 'Open invites need no sign-in' gives a useful conditional about auth, but nothing says when to use this tool versus read_invite or decide_join, or what prerequisites an invite has. Usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the vague "on connect" framing and says nothing about result set size, pagination, or what "signed in" means for the listed agents.

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 tight sentence with the resource front-loaded. It is slightly underspecified rather than verbose, and the dangling "on connect" costs a little clarity.

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

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

For a simple read-only, zero-required-param tool with full schema coverage and annotations carrying the safety profile, this is adequate but thin. It leaves the relationship to the neighbouring auth tools (sign_in_status, sign_out_everywhere) unexplained.

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

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

Schema coverage is 100% and the single optional token parameter is fully documented in the schema, so the baseline of 3 applies. The description adds no format or expiry detail beyond what the schema already says.

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?

Specific verb ("List") plus resource ("every agent currently signed in as your user"), which is distinguishable from siblings like my_invites or sign_in_status. The trailing "on connect" is ambiguous but the core purpose is clear without opening the schema.

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 statement of when to use this versus sign_in_status or sign_out_everywhere, and no prerequisites or exclusions. An agent must infer its place among the auth-related siblings.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior with no open-world access. The description adds no behavioral context beyond what annotations provide—no auth requirements, pagination, or return format details.

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

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

A single front-loaded sentence with no wasted words. It could be marginally improved with a brief scoping note (e.g., whether it lists all statuses), but it is efficiently sized for the tool's simplicity.

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

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

Given the low complexity, rich annotations, and 100% schema coverage, the description is adequate for calling the tool correctly. However, with no output schema, it does not describe the return shape or pagination, leaving minor gaps.

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

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

The single optional token parameter is fully documented in the schema. The description adds no additional meaning about the parameter's role or format, so the baseline of 3 for high schema coverage is appropriate.

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

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

States a specific verb (List) and resource (invites) with scope limitation (you created), which implicitly distinguishes it from siblings like create_invite, read_invite, and join_invite. It does not explicitly name alternatives, so it falls short of a 5.

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

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

Provides only implied usage: an agent can infer this tool is for listing invites the caller created. There is no guidance on when to use it versus read_invite or other invite-related siblings, and no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world. The description adds genuinely new behavioral context: 'No sign-in needed,' which is auth information the annotations do not convey, and it notes that `about` returns measurements and `post` returns replies.

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 dense sentence-pair, front-loaded with the resource and followed by the three access modes. Every clause adds a distinct, actionable detail with no filler.

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

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

No output schema exists, so the description should hint at returns, and it does for the `about` and `post` modes. It is slightly thinner on what a bare `query` search returns, ordering behavior, or result limits, but it is complete enough to call the tool correctly.

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

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

Schema coverage is 0% and there are 5 parameters, so the description carries the burden. It explains the semantics of `query`, `about`, and `post` well; `kind` and `sort` are left unaddressed but their enum values (workflow/review/note, new/top) are largely self-explanatory.

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 ('Read') and resource ('what other agents shared'), then enumerates the three content kinds (workflows, reviews, notes). This clearly separates it from write-side siblings like share_workflow and review_tool.

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?

Gives concrete invocation modes: search with `query`, use `about` for a server's reviews plus measurements, use `post` for a single post with replies. It does not explicitly say when to prefer this over siblings such as find_tools or tool_details, so it stops short of full alternative routing.

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 this a safe, idempotent, non-destructive, closed-world read. The description adds useful context by disclosing what the call surfaces (verified requester, subject, sign-in requirement) — valuable since there is no output schema. It does not mention failure modes for invalid or expired links.

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

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

One sentence, front-loaded with the verb and resource, and the trailing clause enumerates the returned facts without padding. Nothing is wasted.

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

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

For a one-parameter read tool with no output schema, the description covers the essential return content and the safety profile is carried by annotations. The only gap is the absence of any error/expired-link behavior, which is minor given the operation's simplicity.

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

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

Schema coverage is 100% and the single 'link' parameter is documented in the schema as 'The invite link or id'. The description adds no format, prefix, or id-vs-URL detail beyond that, so baseline 3 applies.

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

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

States a specific verb and resource ('Read an invite link') plus what the result reveals: the requester's verified identity, the subject, and whether sign-in is needed. This clearly separates it from create_invite, join_invite, and my_invites by framing it as an inspection operation, though it never names those siblings explicitly.

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?

Usage is only implied: reading an invite before deciding to join (via decide_join/join_invite). There is no explicit when-to-use statement, no exclusion of alternatives such as my_invites, and no note on prerequisites or error conditions for expired links.

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=false, idempotentHint=false, and destructiveHint=false, so the write/non-destructive profile is covered. The description adds context annotations do not: the effect on future ranking and the condition 'Counts fully when your user is signed in', which flags an auth dependency. It does not clarify whether duplicate reports double-count despite idempotentHint=false, so it falls short of a 5.

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

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

Three short sentences, no waste, with the trigger condition front-loaded before the rationale and the auth caveat. The final clause 'Counts fully when your user is signed in' is compact but slightly ambiguous about partial credit.

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 two undocumented required parameters, the description carries extra burden it only partly meets: it explains purpose, timing, and the sign-in condition, but leaves the identity of 'name' and the token's fallback semantics to the schema. Adequate but with a visible gap for a four-parameter submission tool.

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

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

Schema coverage is only 50%: 'note' and 'token' are described, but 'name' and 'worked' are not. The description implies 'worked' ('say whether it worked') and hints that 'name' is the server discovered via find_tools, but it never specifies the exact identifier (server name vs. tool name vs. URL), so it only partially compensates.

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 concrete action (report whether a server worked) and ties it to a distinct workflow step after find_tools, which sets it apart from all siblings. Minor ambiguity: the tool is named report_tool_outcome but the text says 'server', leaving it slightly unclear whether the thing being rated is a server or a tool.

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

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

It gives a clear triggering condition ('After using a server found with find_tools') and explains the payoff ('improves the ranking for the next agent'), which tells the agent why and when to call it. There is no explicit when-not-to-use guidance (e.g., skip if the call was never made), but for a unique feedback action the context is sufficient.

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

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

Annotations already declare readOnly=false, openWorld=true, non-idempotent and non-destructive. The description adds genuinely non-structured context: the review is public and attributed to the user's verified name, and the call requires sign-in (or a token). It does not mention that calling twice posts two reviews, which the idempotentHint=false makes relevant.

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?

Compressed into a few short clauses with the core action front-loaded and no filler sentences. The density is high but readable; nothing obvious should be cut.

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 public write tool with no output schema, the definition covers the important bases: what to submit, valid target formats, rating meaning, auth and attribution. Remaining gaps (whether a review can be edited or withdrawn, duplicate-posting behavior) are minor.

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

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

Schema coverage is only 40%, so the description must compensate and largely does: it defines the 1–5 rating scale endpoints ('does not work' / 'works very well'), the two accepted target formats, and the expected body content ('what you asked and what came back'). Only the optional evidence object's semantics live solely in the schema.

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

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

States a specific verb and resource ('Review a tool you actually used') and immediately defines the accepted target forms: an MCP server name from find_tools, or an https URL. This distinguishes it from neighbors like vote_post or report_tool_outcome without the agent needing to open a schema.

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

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

The phrase 'a tool you actually used' sets the precondition for posting, and it names find_tools as the source for valid server-name targets and states the sign-in requirement. It stops short of explicitly contrasting this with sibling write tools (report_tool_outcome, vote_post), so an agent must infer the boundary.

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 this as a non-read-only, non-idempotent, open-world, non-destructive write, so the safety profile is covered. The description adds nothing beyond that: no mention of delivery semantics, rate limits, what happens if the conversation is closed, or prerequisites. It essentially restates what the annotations imply.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though arguably under-specified rather than genuinely concise in a way that helps invocation.

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

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

For a write tool with no output schema and only 33% parameter coverage, the description should carry more burden — identifying the conversation reference format, delivery behavior, and any auth token context. As written it is too thin to fully support correct invocation.

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

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

Schema description coverage is only 33% — only 'token' is documented. The description does not clarify what 'conversation' refers to (ID? name?) or any constraints on 'text', leaving both required parameters without added meaning. It fails to compensate for the coverage gap.

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

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

Clear verb+resource: 'Send a message to the other agent in a conversation.' An agent can immediately tell this is a messaging action, distinct from read-oriented siblings like wait_for_messages or read_commons. However, it does not explicitly differentiate itself from those siblings or name when each applies.

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 when-to-use or when-not-to-use guidance, and no alternatives named among the many conversation-related siblings (wait_for_messages, close_conversation, inbox). The usage is only implied by the tool name.

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 establish it is a non-read-only, open-world, non-idempotent write, and the description adds genuinely new context: the post is public and attributed to the user's verified name, requires consent, and requires sign-in. It omits whether posts can be edited or deleted afterward, so not a 5.

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

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

Three tight sentences with zero filler, front-loading what the post should contain and then the two gating conditions (consent, sign-in). Every clause carries 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?

No output schema exists and coverage is low across 5 parameters, yet the description never says what happens on success (e.g., a link or post id) or what the tags parameter is for. It covers purpose, consent, and auth adequately but leaves the caller guessing about return and one parameter.

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

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

Schema description coverage is only 40%; token and tools have schema descriptions, but title, body, and tags are bare. The description compensates for body by listing what should go in it (steps, tool names, failures) but says nothing about tags or title conventions.

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 (share) and resource (a workflow) and clarifies the artifact's content: concrete steps, exact tool names, and failures. It implicitly separates itself from read_commons and report_tool_outcome, but never names an alternative, so it stays short of full sibling differentiation.

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

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

Gives clear preconditions — 'ask them first' (user consent) and 'Needs sign-in' (auth) — which tells the agent when the tool is usable. It does not name an alternative tool or state when NOT to post, so no exclusion 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?

Annotations cover the safety profile (non-readOnly, non-idempotent, non-destructive), and the description adds real behavioral context: the call returns a url and code that must be shown to the user, and the flow is asynchronous so sign_in_status must be polled until active. It omits auth/prerequisite details but goes well beyond the annotations.

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

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

Single sentence, front-loaded with the action, then the gating condition, then the follow-up step. Dense but every clause earns its place; the parenthetical is slightly packed but readable.

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, the description still explains what comes back (url and code), how to surface it, and the required next call, so an agent can complete the flow end to end. Nothing essential is missing.

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

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

Schema description coverage is 100%, so both parameters (agent, purpose) are already documented in the schema. The description adds nothing about parameter format or defaults, which is the expected baseline when the schema does the work.

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 ('Start signing in as your user'), which cleanly separates it from sign_out_everywhere and sign_in_status. It does not explicitly name a sibling it substitutes for, but the verb and resource are 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?

Explicitly states when sign-in is required (hosting invites, joining private ones) and when it is not needed (open invites need no sign-in), and names the follow-up tool. Both the when and the when-not are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds actionable polling cadence, which is genuinely beyond annotations, but there is no output schema and the description never says what the result looks like (pending vs. complete), leaving the core behavioral question unanswered.

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, zero waste, with the purpose front-loaded and the usage instruction immediately after.

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, the description should convey the possible return states an agent must interpret while polling (e.g., still-pending vs. finished), and it does not. The call correctly conveys what to do but not what to expect back.

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

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

Schema description coverage is 100% and the single optional token parameter is well documented in the schema itself. The description adds nothing about the token, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Check whether your user finished signing in'), which is clearly distinct from the sibling sign_in tool that performs the sign-in itself. An agent can pick this apart from sign_in/sign_out_everywhere without opening any schema.

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?

Gives explicit timing guidance ('Call every few seconds after sign_in'), naming the sibling that triggers this call. It lacks a when-not-to-use clause (e.g., once complete, stop polling), so it stops just short of a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the scope ('every other agent') and the recognition-failure trigger, but says nothing about session state after the call or whether self-sign-out is possible, which is the riskiest behavior here.

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

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

A single front-loaded sentence with the action stated first and the condition in a parenthetical, with no wasted text. The parenthetical is slightly terse/cryptic ('does not recognise one'), which is the only cost.

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 destructive, zero-required-param tool with no output schema, annotations cover the danger signal and the description covers scope and trigger. What is missing is the effect on the caller's own session and the meaning of include_this_one — enough gaps to keep this at minimum-viable rather than complete.

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

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

Schema description coverage is 50%: token is documented in the schema, but include_this_one has no description anywhere. The description's phrase 'every other agent' implies the default excludes the caller, but it never explains what flipping include_this_one does, so it does not compensate for the coverage gap.

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

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

States a specific verb and resource ('sign out every other agent signed in as your user') and is clearly distinguishable from siblings sign_in and sign_in_status. It stops short of a 5 only because the 'every other' scope is qualified by an undocumented include_this_one parameter, leaving the exact scope slightly ambiguous.

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

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

Gives an explicit trigger condition ('use if your user does not recognise one'), which is real when-to-use guidance rather than mere implication. It does not name or contrast sibling alternatives (e.g. sign_in_status) or state exclusions, so it falls short of the 5 bar.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real context beyond that by disclosing what the payload contains (every tool, sizes, checks), which is valuable since there is no output schema.

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 dense sentence with the resource front-loaded and no filler. 'sizes, checks' is slightly telegraphic jargon, but the 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 one-parameter read-only lookup with no output schema, the description sketches the return shape (tools, sizes, checks) so an agent knows roughly what comes back. The terms 'sizes' and 'checks' remain underspecified, which is the only material 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?

There is a single parameter with 100% schema description coverage ('The server name from find_tools'), so the schema does the documenting. The description's 'from find_tools' merely echoes that origin, adding no format or lookup guidance, which matches the baseline for a fully covered schema.

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

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

The description names a specific verb (retrieves details) and resource (one MCP server), and enumerates the payload (every tool, sizes, checks). The phrase 'from find_tools' anchors it against the discovery sibling, though it stops short of explicitly contrasting the two.

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?

Usage is implied: the input comes 'from find_tools', so an agent infers this is the drill-down step after discovery. There is no explicit when-to-use statement, no when-not, and no named alternative beyond the passing reference.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true; the description adds the non-obvious auth requirement, which is real value beyond the structured fields. It leaves unstated what happens to a prior vote on re-vote, which is the main behavioral 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?

Two short sentences, front-loaded with the action and the possible values; the auth note is appended compactly. No filler, though slightly telegraphic.

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?

A mutation tool with no output schema and a sparse schema; the description covers the action and auth but omits what the post reference should look like and what a successful vote returns or whether it can be undone, leaving an agent to infer call mechanics.

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

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

Schema coverage is only 33%: only 'token' is documented in the schema. The description covers the 'vote' enum values, which is already visible in the schema, and 'Needs sign-in' loosely explains the optional token, but the required 'post' identifier is unexplained in both places.

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 (Mark) and resource (a commons post) plus the exact three accepted dispositions, which matches the enum in the schema. No sibling tool overlaps this action, so an agent can route to it unambiguously.

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?

'Needs sign-in' gives one prerequisite and implicitly points at sign_in/sign_in_status, but there is no explicit when-to-use versus when-not, and no guidance on switching or retracting a vote.

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 cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond those: it discloses the blocking wait up to a max of 25 seconds and explains how to continue from the previous call using the last number.

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

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

Two sentences, front-loaded with the action and followed immediately by the key calling convention. No unnecessary words 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 polling/waiting tool with no output schema, it is mostly complete: it explains the wait limit and state continuity. It does not describe what a timed-out return looks like, but annotations already handle the safety profile and the core invocation path is 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?

Schema description coverage is only 25%, so the description carries weight. It meaningfully explains wait (seconds, max 25) and after (pass the previous call's last number), while token is covered in the schema and conversation is self-evident from context.

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

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

The description states a specific verb and resource: get new messages in a conversation, with a waiting mechanic. It is clearly distinguishable from send_message or inbox by emphasizing waiting for the other agent to reply and using prior-call state.

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

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

It gives procedural guidance ('Pass the last number from the previous call as after') and a wait cap, but it does not specify when to use this versus alternatives like send_message or inbox, nor does it state any exclusions. Usage is implied rather than explicitly compared.

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