freeq

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

Annotations already mark the tool as read-only and not open-world, and the description adds useful behavioral detail: invite-only, key-protected, and encrypted-only channels are never listed, and no authentication is required. This goes beyond the annotations and helps the agent understand the filtering and access semantics.

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

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

Three short sentences with no wasted words. The main action is front-loaded, followed by usage guidance, exclusions, and auth requirement. Each sentence adds value.

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

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

For a zero-parameter read-only tool with an output schema, the description is complete. It explains what is returned, when to use it, what is excluded, and that authentication is not required. No important information is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters, so parameter documentation is not needed. The description still covers the output focus with 'member counts and topics', and the schema is fully covered by the absence of parameters.

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: 'List the public channels on this server' with member counts and topics. It also clarifies scope by explicitly excluding non-public channels, which distinguishes it from the sibling tools that deal with history, pins, search, and verification.

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 'Start here when you do not know a channel's exact name' gives clear guidance on when to use this tool. It implies this tool is the entry point before using search or other channel-specific tools, though it does not explicitly name alternatives or describe 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?

Annotations mark this read-only, and the description adds useful beyond-annotation context: public channels need no authentication, restricted channels need a bearer, and messages are returned newest first. However, the pagination note calls `before` the 'oldest msgid,' which conflicts with the schema's explicit 'timestamp field, not the msgid,' slightly reducing reliability.

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 three tight sentences, front-loaded with the core action and then adding only essential extras: ordering, pagination, and authentication. The pagination sentence contains a factual error, but the structure itself is efficient and 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?

With an output schema and annotations present, the description does not need to explain return values, and it does cover ordering and auth requirements. The `before`/msgid error leaves the pagination guidance incomplete, and there is no sibling routing, so an agent must rely on the schema to avoid misusing the 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 coverage is 100%, so the baseline is 3, but the description's `before` guidance is actively misleading: it says to pass the oldest msgid, while the schema says `before` is a Unix-seconds timestamp and expressly 'not the msgid.' This misinformation lowers the score.

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 clear verb and resource: 'Read recent messages from a channel' and adds 'newest first,' which matches the title. It does not explicitly contrast with siblings like freeq_search or freeq_pins, so differentiation is left mostly 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 description gives no guidance about when to choose this tool over siblings such as freeq_search or freeq_pins. It discusses pagination mechanics ('Page backwards by passing...') but does not provide when-to-use or when-not-to-use context for 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?

The readOnlyHint annotation already establishes safety, so the bar is lower. The description adds useful behavior context: pins are operator-controlled, usually containing rules/links/standing context, and reading them is cheaper than history. This goes beyond the annotation without contradicting 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 concise sentences carry the purpose, content expectations, and cost comparison with no wasted words. The use case is front-loaded and the alternative is mentioned efficiently.

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 operation with a readOnlyHint, an output schema, and clear sibling context, the description covers what pins are, when to use them, and why they are preferable to history. 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 coverage is 100% and the single channel parameter is already well described in the schema, including the leading-# flexibility. The description adds no additional parameter-level detail, so the baseline of 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?

The title supplies the verb 'Read' and the resource 'pinned messages', and the description explains what pinned messages typically contain (rules, links, standing context). It also distinguishes itself from freeq_history by noting it is cheaper, so an agent can tell it apart from at least one sibling.

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

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

The description explicitly says to use this when you want to know what a channel is for, and positions it as cheaper than reading history. It does not, however, give explicit when-not-to-use guidance or compare against freeq_search and freeq_verify.

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 signal readOnlyHint=true, and the description adds useful behavioral context: the search is full-text, scoped to one channel, and shares access rules with freeq_history. It does not describe edge cases or result ordering, but the output schema reduces the need for that.

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

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

Three short sentences each earn their place: purpose, usage guidance, and access-rule reference. The information is front-loaded and there is 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?

With a complete input schema, an output schema, and read-only annotations, the description covers the important operational choices: which tool to use, what scope it operates on, and what access expectations to carry. The reference to freeq_history is reasonable within the sibling-tool 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 description coverage is 100%, so channel, q, and limit are already documented. The description does not add nuance about search syntax or limit behavior, so it neither improves nor harms the parameter understanding beyond 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?

The description names a specific operation: full-text search within one channel. It clearly distinguishes itself from sibling tools by contrasting with 'paging history' and makes the scope explicit.

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 an explicit condition for use ('when you know roughly what was said') and names the alternative ('paging history'). This lets an agent decide between freeq_search and freeq_history without additional 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?

The description adds meaningful behavioral context beyond the readOnlyHint annotation by explaining the semantic difference between signed_by 'author' and 'server,' including the non-repudiation property and the limitation of relay-only proofs. This helps the agent reason about the trustworthiness of the result.

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

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

The description is compact and well-structured, leading with the core purpose, then explaining the critical semantic distinction, and ending with actionable guidance. Every sentence adds value with no 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 single-parameter tool with an output schema and read-only annotations, the description is complete. It covers what the tool does, when to use it, what the signed_by values mean, and how to avoid misrepresenting results.

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 already documents the single msgid parameter as a ULID message id, so schema coverage is 100%. The description does not add parameter-specific syntax or format details, but it does not need to because the schema fully covers the parameter meaning.

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

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

The description opens with a specific verb and resource: 'Check who signed a message.' It clearly distinguishes the tool's purpose from the sibling tools, which are about channels, history, pins, and search, none of which address signature verification.

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 explicitly says when to call the tool: 'Call this before quoting anyone as having said something.' It also provides a clear exclusion by warning not to present a server-relayed message as author-signed, giving the agent actionable usage context.

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