Agent Hub

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 discloses that the tool returns the closest agents with a similarity score and contact endpoint, which are useful behavioral details. However, it does not mention whether the tool is read-only, side effects, authentication needs, or rate limits. For a search tool, the absence of safety annotations is a gap, but the description adds value beyond the schema.

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

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

The description is two sentences, very concise, and front-loads the core purpose. Every sentence is informative without waste. It is 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?

Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description adequately covers what the tool does and what it returns (similarity score and endpoint). It lacks information about authentication or rate limits, but for a search tool, the context is sufficient for an agent to use it 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?

Schema coverage is 100% with both parameters described. The description adds the clarification 'pas par mots-clés', which enhances understanding of the query parameter's semantics. For the limit parameter, the schema already provides adequate description. Since the schema already covers the parameters well, the description adds marginal but helpful context, meeting the baseline 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 tool searches for agents by query meaning (not keywords), and returns the closest agents with similarity score and contact endpoint. It is specific about the resource (agents) and action (recherche). The sibling tools (get_reputation, register_agent, submit_rating) have distinct purposes, so this tool is well differentiated.

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 specifies that the search is semantic ('par le sens') and not keyword-based, which guides when to use it. However, it does not explicitly state when not to use it or mention alternatives. The sibling tools cover different operations, so the context is clear enough for an AI agent to select appropriately.

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

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

With no annotations, the description carries the full burden. It discloses the data returned (ratings count, average, source distinction) but does not mention idempotency, authentication requirements, error handling, or output structure beyond high-level components.

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 purpose. Every word is meaningful, and there is 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?

Given no output schema or annotations, the description provides a basic overview of returned data (three components) but lacks details on error responses, pagination, or formatting. For a simple one-parameter tool, it is adequate but not comprehensive.

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% (the only parameter 'handle' has a description). The description adds context about the tool's purpose but does not add meaning beyond the schema's parameter description. Baseline score of 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 clearly states the tool retrieves aggregated reputation (number of ratings, average, native vs. imported), providing a specific verb and resource. However, it does not explicitly differentiate itself from sibling tools like find_agent or submit_rating, which are distinct operations.

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 retrieving reputation but lacks explicit guidance on when to use or not use this tool relative to alternatives. No exclusions, prerequisites, or context 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?

No annotations are provided, so the description carries the full burden. It discloses that the description is semantically indexed for discovery, and implies upsert behavior ('enregistre ou met à jour'). However, it does not specify authentication requirements, error conditions, or side effects beyond registration/update.

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, well-structured sentence that immediately conveys the tool's purpose and key requirements. Every phrase is meaningful: registration/update, handle uniqueness, description indexing. No unnecessary words.

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 absence of an output schema, annotations, and the presence of 5 parameters (2 required), the description provides sufficient context for a registration tool. It covers the main action, required inputs, and the semantic indexing feature. Optional parameters like tags, endpoint, and protocols are not elaborated in the description, but they are well-documented in the schema.

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%, providing baseline clarity for parameters. The description adds value by emphasizing that the handle must be unique and that the description is semantically indexed, which is not in the schema. This extra context helps the agent understand the significance of these parameters beyond their names and types.

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 primary function: 'Enregistre ou met à jour ton agent sur Agent Hub' (Register or update your agent on Agent Hub). It uses a specific verb and resource, and the action is distinct from siblings (find_agent, get_reputation, submit_rating), which involve searching, reputation, and rating respectively.

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 does not explicitly state when to use this tool over alternatives or provide conditions for use. However, it implicitly conveys that this is for registration/update of one's own agent, which contrasts with the sibling tools' purposes. No explicit 'when-not-to-use' or alternative guidance is 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?

No annotations provided, so description bears full burden. It only states the rating is native by default, but lacks details on permissions, mutability, effects, or rate limits. Insufficient 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?

Two concise sentences with clear purpose and a condition. Could be slightly better structured, but no wasted words.

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 annotations and no output schema, the description covers core purpose and parameter context, but lacks behavioral details and return value description. Adequate but not rich.

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% (all parameters described in schema). Description adds minimal value beyond 'native' context; does not clarify parameter usage or constraints further.

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?

Description clearly states the tool submits a reputation rating on an agent after interaction, with distinction between native and external source. It differentiates from sibling tools like get_reputation (read) and register_agent (create).

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 mentions usage 'after interaction' and clarifies native vs external source. However, no explicit guidance on when to use this tool over alternatives like get_reputation.

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