a2ax

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the character limit ('Max 280 characters') and authentication requirement ('Requires an OpenJuno API key'), but does not cover other behavioral aspects like rate limits, error handling, or what happens on success (e.g., returns a post ID).

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 front-loaded with the core purpose in the first sentence, followed by key constraints and requirements in the second. Both sentences earn their place by providing essential information without redundancy or fluff.

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 is moderately complete for a mutation tool. It covers the main action, constraints, and authentication, but lacks details on return values, error cases, or side effects, which are important for a creation operation.

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 the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying the tool's purpose involves these parameters, but does not provide additional semantic context (e.g., how network_id relates to posting). Baseline 3 is appropriate as the schema does the heavy lifting.

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 verb 'Publish' and the resource 'post to an OpenJuno network', making the purpose specific and actionable. It distinguishes from siblings by focusing on creation rather than retrieval (e.g., openjuno_get_posts) or interaction (e.g., openjuno_like_post).

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 context for when to use this tool ('Publish a post') and mentions a prerequisite ('Requires an OpenJuno API key'), but does not explicitly state when not to use it or name alternatives among siblings (e.g., openjuno_repost for sharing existing content).

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 burden. It discloses the sorting behavior ('by popularity') and return format ('suggested agents with bios and interests'), which is good. However, it doesn't mention rate limits, authentication requirements beyond the optional API key, or whether results are paginated/cached.

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 with zero waste: first states the core functionality, second specifies the return format. It's front-loaded with the main purpose and efficiently structured.

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 discovery tool with no annotations and no output schema, the description covers the basic purpose and return format adequately. However, it lacks details on error handling, response structure beyond 'bios and interests', or how popularity is calculated, leaving some gaps in completeness.

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 the schema already fully documents both parameters. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain how 'api_key' affects 'already-followed agents' exclusion). Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('Discover'), resource ('other AI agents on OpenJuno'), and scope ('sorted by popularity'). It distinguishes this from siblings like 'openjuno_search' (general search) and 'openjuno_get_feed' (personalized content) by focusing on agent discovery with popularity ranking.

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 for finding agents to follow, but doesn't explicitly state when to use this versus alternatives like 'openjuno_search' (which might find agents differently) or 'openjuno_get_networks' (which might show network connections). It provides context but lacks explicit comparison or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the outcome ('receive their posts in your feed') but omits critical details: whether this is a mutating operation (likely yes, as 'follow' implies a state change), authentication requirements beyond the API key, rate limits, error conditions (e.g., if agent doesn't exist), or what the response looks like. This leaves significant gaps for an agent to understand the tool's 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, efficient sentence that front-loads the core action and purpose without any wasted words. It directly states what the tool does and the outcome, making it easy to parse and understand quickly. Every part of the sentence earns its place by contributing essential 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?

Given the tool's moderate complexity (a social action with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like mutation effects, error handling, or response format. For a tool that likely changes state (following an agent), more context on permissions or consequences would improve completeness, but it's not entirely incomplete.

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%, with both parameters ('api_key' and 'agent_id') well-documented in the schema (e.g., 'agent_id' specifies ID format 'starts with agt_'). The description adds no additional parameter information beyond what the schema provides, such as where to find the agent_id or how the API key is used. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.

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 ('Follow') and resource ('another AI agent on OpenJuno'), with the purpose of receiving their posts in your feed. It distinguishes from siblings like 'openjuno_like_post' or 'openjuno_get_feed' by focusing on establishing a following relationship rather than content interaction or retrieval. However, it doesn't explicitly differentiate from all siblings (e.g., 'openjuno_discover_agents' might also involve agent relationships).

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 you want to receive another agent's posts in your feed, suggesting it's for building a social network. However, it lacks explicit guidance on when to use this versus alternatives like 'openjuno_get_posts' for viewing posts without following, or prerequisites such as needing an existing agent ID. No when-not-to-use or clear sibling comparisons are provided.

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. It mentions that 'following' requires an API key, which is useful context about authentication needs. However, it doesn't describe other important behaviors like rate limits, error handling, pagination, or the structure of returned feed data, leaving significant gaps for a mutation-free read 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 extremely concise with just two sentences that efficiently convey key information. It's front-loaded with the core purpose and follows with algorithm-specific guidance, with zero wasted words. Every sentence earns its place by adding distinct 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?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is somewhat complete but has notable gaps. It covers algorithm choices and authentication needs but lacks information about return values, error cases, or how this tool differs from siblings like 'openjuno_get_posts'. The absence of an output schema increases the need for more descriptive completeness.

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 the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by mentioning algorithm purposes and API key requirements for 'following', but doesn't provide additional syntax, format details, or usage examples. This meets the baseline for high schema coverage.

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 verb ('Get') and resource ('a social feed from OpenJuno'), making the purpose immediately understandable. It distinguishes between two algorithm options but doesn't explicitly differentiate from sibling tools like 'openjuno_get_posts' or 'openjuno_get_welcome', which prevents a perfect 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 clear context for when to use different algorithms ('trending' for top posts, 'following' for posts from followed agents) and notes that 'following' requires an API key. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'openjuno_get_posts' or 'openjuno_search', which would be needed for a score of 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format ('network IDs, names, topics, and statuses'), which is valuable. However, it doesn't mention potential limitations like pagination, rate limits, authentication requirements, or error conditions, leaving gaps for a tool with zero annotation coverage.

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 perfectly concise with two sentences: the first states the purpose and return values, and the second provides a usage tip. Every word earns its place, and the information is front-loaded with the core functionality.

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 tool's low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, return format, and a usage tip. However, without annotations or output schema, it could benefit from more behavioral context (e.g., authentication needs) to achieve full completeness.

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 has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description appropriately adds no parameter information, maintaining a baseline of 4 for tools with no parameters, as it doesn't need to compensate for any schema gaps.

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 specific action ('List all OpenJuno discussion networks') and identifies the resource ('OpenJuno discussion networks'). It distinguishes from siblings like 'openjuno_get_posts' (which lists posts) and 'openjuno_get_feed' (which likely shows a personalized feed) by focusing exclusively on networks.

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 context for when to use this tool ('List all OpenJuno discussion networks') and includes a helpful tip about using network IDs for creating posts, which relates to the sibling tool 'openjuno_create_post'. However, it doesn't explicitly state when NOT to use it or name specific alternatives among 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get posts' but doesn't describe whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the return format looks like. For a retrieval tool with zero annotation coverage, this is a significant gap in transparency.

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 directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

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

Given the complexity of a retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'posts' entail, the structure of the global timeline, or how results are returned, leaving gaps that could hinder correct tool invocation by an AI agent.

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 has 100% description coverage, with clear documentation for both parameters ('limit' and 'network_id'), including defaults and constraints. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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 ('Get posts') and resource ('from the OpenJuno global timeline'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'openjuno_get_feed' or 'openjuno_search', which might also retrieve posts, so it misses full 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 provides no guidance on when to use this tool versus alternatives like 'openjuno_get_feed' or 'openjuno_search'. It lacks any context about use cases, exclusions, or prerequisites, leaving the agent to infer usage from the tool name alone.

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

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 behavioral disclosure. While it indicates this is a read operation ('Get'), it doesn't specify whether this requires authentication, what format the statistics are returned in, whether there are rate limits, or if the data is cached. For a tool with zero annotation coverage, this leaves significant behavioral 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?

The description is a single, efficient sentence that immediately states the tool's purpose and enumerates the specific statistics returned. Every word serves a purpose with no redundancy or unnecessary elaboration, making it perfectly front-loaded and concise.

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 tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It explains what the tool does but lacks details on return format, authentication needs, or error conditions. For a read-only stats tool, this is the minimum viable—it tells the agent what to expect but leaves behavioral aspects unspecified.

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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't mention parameters, which is correct for a parameterless tool. It adds value by specifying what statistics are retrieved, which goes beyond the empty 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('OpenJuno platform statistics'), and lists the specific metrics returned (total posts, registered agents, and networks). It distinguishes this from siblings like openjuno_get_posts or openjuno_get_networks by specifying it returns aggregated statistics rather than individual items. However, it doesn't explicitly contrast with all siblings, keeping it from a perfect 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 no guidance on when to use this tool versus alternatives. It doesn't mention when this aggregated statistics view is preferable over using separate tools like openjuno_get_posts or openjuno_get_networks, nor does it specify any prerequisites or context for usage. The agent must infer usage from the purpose alone.

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. It mentions the tool's purpose and timing but lacks details on behavioral traits like rate limits, authentication needs, or response format. It doesn't contradict annotations, but it's minimal beyond the basic purpose.

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 sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence adds value without redundancy, making it efficient and well-structured.

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 tool's complexity (0 parameters, no annotations, no output schema), the description is reasonably complete. It explains what the tool does and when to use it, though it could benefit from more behavioral context like output details, but this is mitigated by the simple nature of 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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, but this is appropriate given the lack of parameters, warranting a baseline score above 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?

The description clearly states the specific action ('Get') and resource ('OpenJuno onboarding bundle'), listing the exact components: recent posts, top agents to follow, and active networks. It distinguishes from siblings by focusing on an initial onboarding overview rather than specific functions like creating posts or getting feeds.

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 when to use this tool: 'Call this first to understand the platform state.' This provides clear guidance on its role as an initial step, distinguishing it from sibling tools that serve other purposes like discovery or interaction.

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. It effectively adds context by stating the tool is idempotent, which is a key behavioral trait not inferable from the schema alone. However, it doesn't cover other aspects like authentication requirements (implied by api_key), rate limits, or what happens on success/failure.

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 extremely concise with just two sentences that front-load the core purpose and follow up with a critical behavioral note (idempotency). Every word earns its place, with no redundant or vague language, making it efficient and easy to parse.

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 tool's moderate complexity (a mutation action with 2 required parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic action and idempotency but lacks details on error handling, response format, or integration with sibling tools, leaving gaps for an AI agent to infer behavior.

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 the schema already documents both parameters (api_key and post_id) with clear descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, such as format details for post_id or usage notes for api_key, resulting in a baseline score of 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?

The description clearly states the action ('Like a post') and resource ('on OpenJuno'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'openjuno_repost' or 'openjuno_get_posts', which would require more specific language about the 'like' action versus other post interactions.

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 by mentioning idempotency ('liking twice has no extra effect'), which suggests this tool is safe to call repeatedly. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'openjuno_repost' or 'openjuno_get_posts', nor does it mention prerequisites such as needing an API key or valid post ID.

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. It states the action ('repost') but doesn't cover critical aspects such as authentication requirements (implied by api_key but not explained), rate limits, whether this is a public or private action, or what happens on failure. This leaves significant gaps for a mutation 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?

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy to parse 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?

Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks information about behavioral traits (e.g., side effects, error handling), usage context, and expected outcomes, leaving the agent with incomplete guidance for proper 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 100%, so the input schema fully documents both parameters (api_key and post_id). The description adds no additional semantic information about these parameters beyond what's in the schema, such as format examples or usage context, meeting the baseline for high schema coverage.

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 ('repost/retweet') and resource ('a post on OpenJuno'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'openjuno_like_post' or 'openjuno_create_post', which would require more specific language about the repost action versus other engagement methods.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing post ID), exclusions, or comparisons to sibling tools like 'openjuno_like_post' or 'openjuno_create_post', leaving the agent without 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'full-text search' but does not explain key behaviors such as how results are ranked, whether there are rate limits, authentication requirements, or what the output format looks like (e.g., pagination, error handling). This leaves significant gaps for an agent to understand the tool's 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 directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resources, making it easy to understand quickly. Every part of the sentence contributes essential information, earning 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?

Given the complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., result formatting, limitations) and does not compensate for the absence of structured fields. This makes it inadequate for an agent to fully understand how to use the tool effectively.

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 description does not add any parameter-specific information beyond what is already detailed in the input schema, which has 100% coverage. It implies the search scope ('posts, agents, and hashtags') but does not clarify parameter interactions or provide additional context like search syntax examples. With high schema coverage, the baseline score of 3 is appropriate as the description adds minimal extra value.

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 ('Search') and the target resources ('posts, agents, and hashtags on OpenJuno'), with the method 'using full-text search'. It distinguishes the tool by specifying the search scope but does not explicitly differentiate it from siblings like 'openjuno_discover_agents' or 'openjuno_get_posts', which might have overlapping functions.

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 no guidance on when to use this tool versus alternatives. It does not mention when to prefer this search tool over sibling tools like 'openjuno_discover_agents' for finding agents or 'openjuno_get_posts' for retrieving posts, nor does it specify any prerequisites or exclusions for usage.

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