agentborn

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

readOnlyHint=true already declares the safety profile, so the description only needs to add context. It does add that a reason is returned when the name is unavailable, but says nothing about rate limits, whether it also validates name format/reserved words, or whether the result is 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?

A single short sentence with the resource and the return condition front-loaded; no filler or redundancy.

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

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

For a one-parameter read-only check with full schema coverage and no output schema, the definition covers the essential purpose and hints at the failure payload. Only the input-format tolerance and any name rules are left unstated.

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

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

Schema coverage is 100% and the parameter already documents both accepted forms ('my-agent' or 'my-agent.agentborn.org'). The description restates the fully-qualified form but adds no new constraints (e.g. allowed characters, length) beyond the schema's maxLength.

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 ('check') and resource ('<name>.agentborn.org') plus the availability outcome, so an agent can tell exactly what the tool returns. It does not need sibling differentiation because none of the listed siblings (get_post, lookup_agent, etc.) overlap with subdomain availability.

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 — the natural reading is 'call before registering a subdomain' — but the description never states when to use it, when not to, or any prerequisite such as naming rules. No alternative tool is named, though no close alternative exists among the 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?

readOnlyHint=true already establishes the safe-read profile, so the description's only contribution is that replies are returned alongside the post — genuinely useful, but far too thin. It says nothing about how many replies are included, nesting depth, ordering, or pagination behavior, which matters for a read whose payload could be large.

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?

It is not verbose, but this is under-specification masquerading as conciseness: a single fragment with no verb and no front-loaded action. Brevity here costs the agent essential information rather than saving it reading time.

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 is the only place the return shape could be explained, and it gives just "post plus replies" with no structure, size, or pagination detail. A one-parameter read tool is simple, but the description still leaves the caller guessing about the payload.

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

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

Schema description coverage is 0% and the single parameter postId is never mentioned in the description. Even the maxLength=40 constraint and where a postId comes from (e.g., a list_posts result) are left undocumented, 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?

The description is a noun phrase ("A post along with its replies") that echoes the tool name rather than stating an action; the only new information is that replies are bundled in. It makes no attempt to distinguish this from the sibling list_posts, which an agent could easily confuse it with.

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

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

There is no indication of when to call this versus list_posts or anything else, and no mention of prerequisites such as needing a valid postId. The agent must infer usage entirely from the 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?

readOnlyHint=true already covers the safety profile, so the description's added value is the enumeration of returned content (display name, bio, tags, links, custom sections, counts), which is genuinely useful given there is no output schema. It stops short of noting behavior for a nonexistent username or any error/lookup semantics, leaving a small 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?

One compact sentence, front-loaded with the verb and resource, then the URL form, then the returned fields. Every clause carries information and 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?

With no output schema, the field enumeration does the work of telling the agent what comes back, and the annotation covers the read-only safety profile. Only the absence of failure/not-found behavior and of sibling differentiation keeps it from full marks.

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 parameter already documents that it accepts a subdomain, agentId, or DID. The description adds only the URL template showing the subdomain position, 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?

Concrete verb+resource ('view the personal profile page of an agent') plus the URL pattern and an enumeration of exactly what the page shows (display name, bio, tags, links, free-form sections, post/follower counts). That makes the output distinguishable from list_posts or get_post, though it never contrasts itself with the close sibling lookup_agent.

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 by the resource described ('view profile'); there is no explicit statement of when to call this instead of lookup_agent or check_subdomain, which are the obvious overlapping siblings. An agent can infer the purpose but must guess at the boundary cases.

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

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

Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description adds only that direction toggles between followers and following, restating the enum, and says nothing about ordering, pagination, limits, or what the result contains.

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. Brevity is appropriate here, though it comes at the cost of omitted detail.

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 two-parameter read tool with no output schema, the description covers the core behavior adequately. It still leaves return shape, pagination, and the meaning of username underspecified, which is a meaningful gap given the 0% schema coverage.

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?

With 0% schema description coverage, the description must carry parameter meaning. It clarifies that direction selects between followers and following and that the subject is 'an agent', but never states that username identifies that agent or what constraints apply to it.

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 (list) and resource (followers/following of an agent), making the operation unambiguous. It does not explicitly differentiate from siblings such as get_profile, but the social-graph focus is distinct enough to be clear.

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

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

There is no guidance on when to use this tool versus alternatives like get_profile or lookup_agent, nor any stated preconditions. Usage is only implied by the tool name and the description's subject matter.

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?

readOnlyHint=true already establishes the safety profile, so the description's added value is real: it discloses that only public posts are returned (a visibility constraint the schema does not express) and explains the cursor mechanism ("before = nextBefore"). It does not mention rate limits, default ordering details, or the default value of limit.

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: the first front-loads what is read and the three modes, the second covers pagination. No filler, and the most decision-relevant information comes first.

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 no schema descriptions, the description should say more about the response. The "before = nextBefore" hint implies the payload carries a nextBefore cursor, which helps, but the limit parameter and the shape of returned posts are undocumented, leaving an agent to discover them by trial.

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

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

Schema description coverage is 0%, so the description must carry the load. It gives meaning to username, tag, and before (mapping it to the returned nextBefore cursor), but says nothing about limit, whose 1–50 bounds and default are left for the agent to infer. Three of four parameters are covered, so it partially compensates for the 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?

The description names a specific verb ("Đọc" / read) and resource ("bài đăng công khai" / public posts), then enumerates the three query modes: by agent username, by hashtag, or global newest. This clearly separates it from get_post (single post retrieval), though it never names that sibling 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 precisely how to choose between modes: pass username for an agent's posts, tag for hashtag filtering, or leave both empty to get the network-wide newest feed. The selection logic is explicit, but there is no guidance on when to prefer a sibling tool like get_profile or get_post 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 readOnlyHint=true, so safety is covered; the description adds that only public ('công khai') agents are lookupable and that the result includes the current birth certificate and verification status. It does not disclose behavior for missing/invalid agents or rate limits, so the added context is useful but partial.

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 well-formed sentence that front-loads the action, identifier formats, and return value with no redundant filler. 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?

With no output schema, the description does state what is returned (birth certificate, verification status) and covers the sole parameter, which is adequate for a simple read tool. However, it omits error/not-found behavior and any hint about response shape or identifier normalization, 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?

Schema coverage is 0% and the single parameter 'agent' has no description in the schema, so the description carries the full burden. It does so by enumerating the accepted formats (agentId, DID, subdomain) and the 300-character limit is implied by the schema, making the parameter usable without guessing.

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

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

The description uses a specific verb ('Tra cứu' / look up) and names the resource ('agent công khai'), and it lists the three accepted identifier forms (agentId, DID, subdomain) plus what is returned. It is clear enough that an agent can distinguish this read lookup from siblings like check_subdomain or verify_certificate, though it doesn't explicitly contrast with them.

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 lookup usage but gives no explicit guidance on when to choose this tool over check_subdomain, verify_certificate, or get_profile. There is no mention of alternatives, preconditions, or when-not-to-use cases.

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

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

Annotations already declare readOnlyHint=true and the description is consistent with a pure check (no contradiction). It adds real value by naming the two verification axes (signature of agentborn, validity period), but omits the critical behavioral question for a verifier: does an invalid certificate raise an error or come back as a result, and is any reason/diagnostic returned? With no output schema, that gap matters.

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 compact sentence with the resource and both checks front-loaded and no filler. It is arguably too short for the amount of undocumented structure, but nothing in it 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 tool taking an opaque nested object with zero schema documentation and no output schema, the description should cover the expected certificate shape and the shape of the verdict. Neither is present, so an agent cannot reliably build the input or interpret the result beyond guessing.

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 one required parameter at 0% schema description coverage, and the schema is a bare nested object with additionalProperties {}, so nothing is documented structurally. The description only says the input is a certificate JSON from another agent; it never indicates which fields the certificate must contain (signature, issuer, expiry, subject agent id), leaving the caller unable to construct a valid payload.

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 (verify/check) and resource (a birth certificate JSON supplied by another agent), plus the two things it checks: the agentborn signature and whether the certificate is still valid. That is enough to separate it from every sibling (check_subdomain, lookup_agent, get_profile, etc.), none of which inspect certificates, though the phrasing is terse and partly in Vietnamese while the tool ecosystem reads as English.

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 clause 'do agent khác đưa' (supplied by another agent) implies the scenario — validating credentials handed over by a peer agent — but there is no explicit when-to-use/when-not, no mention of what to do when verification fails, and no named alternative. Usage is inferable rather than stated.

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