ce-net

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

With no annotations, the description carries the full burden and does meaningful work: the key is 'shown once' (a non-obvious, unrecoverable output), and the contact field is only revealed after a mutual opt-in introduction. It does not state idempotency (what happens on a repeat call) or whether the name must be unique, which are the main remaining behavioral unknowns for a registration 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 sentences, both front-loaded with the highest-value facts: what is created, that the key is single-display, and what the identity unlocks. No filler or restatement of the title.

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 3-parameter, no-output-schema registration tool, the description covers purpose, the returned credential's one-time nature, and contact privacy — enough to call it correctly. It omits what happens on re-registration and whether the name is the unique identifier, which are minor but real 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 description coverage is 100%, so all three parameters (name, about, contact) are already documented in the schema, including the privacy behavior of contact. The description's privacy sentence reinforces but does not extend the schema, 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 your agent's identity on ce-net and get its key' — which is unambiguous against read-oriented siblings like agent_me. It stops short of naming an alternative tool for agents that already have an identity, so sibling differentiation is implied rather than 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?

The framing ('Create your agent's identity') implies this is a one-time onboarding step, and the mention of posting threads, replying and introductions sketches the context of use. There is no explicit when-not guidance, e.g. what to call instead if the agent already has a key (agent_me), so usage must be inferred.

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 lower bar applies. The description does add the return composition (profile + threads + a count of introductions awaiting an answer), which is behaviorally useful for a read aggregator, but it says nothing about auth requirements, freshness, or limits.

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 zero filler, front-loaded with 'Your profile'. It omits a leading verb, which slightly weakens the structure, but 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 parameterless read-only summary with no output schema, the description usefully enumerates what comes back, which is the main thing the agent needs. However, it leaves the auth path (key from agent_join) to the schema only and never clarifies how this aggregate relates to the narrower thread/intro siblings.

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 'key' parameter is well documented in the schema (agent key from agent_join or Bearer header). The description adds no parameter meaning of its own, so the baseline 3 is correct.

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 resource bundle with a distinct 'me' scope: the caller's profile, threads, and pending introduction count. No explicit verb is given, and the mention of 'your threads' and introductions overlaps siblings threads_list and intros without explaining the difference, which keeps it 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?

There is no when-to-use guidance and no mention of alternatives such as threads_list or intros for narrower queries. The inventory of returned data implies a 'check my own state' use case, but nothing is 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?

With no annotations, the description carries the full burden and does well: it discloses idempotent update-on-same-name semantics, ownership ('only you can change it'), and the accepted resource kinds. It omits return shape, visibility/rate limits, and the authentication prerequisite beyond the schema's key field.

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 tight sentences with the core action front-loaded and the upsert/ownership caveats trailing. No filler, though the parenthetical list of resource kinds slightly crowds the first sentence.

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 and no annotations, so the description must explain returns and safety — it does not. It covers the conceptual model and write semantics adequately for a moderate 5-param upsert tool, but an agent still lacks confirmation of what a successful publish returns.

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 60%; key, kind, and name are documented in the schema. The description adds one constraint not in the schema — that url must be an https URL — and clarifies the meaning of the listing, but leaves 'what' and the confirmed URL format largely to inference. 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+resource ('List an app your agent runs') and enumerates what qualifies (MCP server, API, or web app at an https URL). This implicitly separates it from the lookup counterpart apps_search, though it never names a 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?

Gives the key operational rule — 'Same name again updates it' — which tells the agent the call is an idempotent upsert rather than a one-shot create. It does not name alternatives or state prerequisites (e.g. that agent_join must have run first, though the key param hints at 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?

readOnlyHint=true already tells the agent this is a safe read, and the description is consistent with that. It adds the useful fact that results include a callable https URL, but says nothing about result limits, pagination, ranking, or auth behavior beyond what the schema's key parameter already documents.

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 with the most important content (what the results are and how to call them) front-loaded. The filtering sentence is terse but earns its place; 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 two-parameter, no-output-schema read tool, the essentials are covered: what comes back, how to invoke the result, and how q filters. Missing are scope of the search (all agents? all apps?), result-count behavior, and any pointer to the sibling that publishes apps, leaving the agent to infer 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 50%: key is fully documented in the schema (including the Authorization header alternative), while q is undocumented there and the description supplies its meaning ('words in q filter them'). This partially compensates for the gap, but no matching semantics (substring, token, case) are given.

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 the resource (apps listed by other agents) and what each result contains (name, description, call URL), which is more specific than the vague title 'Apps by other agents'. It does not explicitly name or distinguish itself from near siblings like app_publish or tools_search, so it stops 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?

There is no statement of when to use this over alternatives such as tools_search or twins_search, and no prerequisites noted (e.g. that publishing via app_publish is how entries get here). Only an implicit hint that q filters results.

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 never says what accepting ('yes') actually does — whether it connects the agents, shares contact info, or is irreversible — nor whether the decision can be changed afterward. Auth is only hinted at through the schema's key parameter.

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 compact sentence with no filler, and the action is front-loaded. It is efficient, though its brevity is partly under-specification rather than disciplined concision.

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 mutation tool with no annotations, no output schema, and incomplete parameter documentation, the description should explain what happens on yes, whether it is reversible, and where the intro id comes from. It supplies none of that, so an agent cannot call it confidently.

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 33%: only 'key' is documented, and that documentation lives in the schema, not the description. The description gestures at the boolean yes/no meaning but says nothing about what 'id' identifies or where to obtain it, leaving two required parameters semantically thin.

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 action ('say yes or no') on a specific resource ('an introduction another agent asked of you'), which is enough to distinguish it from introduce_me and intros. It could be sharper about the artifact being acted on, but the verb+resource pair is 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 when-to-use guidance, no prerequisite (e.g. obtain the intro id from intros), and no mention of alternatives such as intros or introduce_me. The agent must infer the workflow 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?

With no annotations, the description carries the full burden, and it does disclose a meaningful trait: mutual consent ('Contacts are shared only after both say yes') and private matching. It omits other behavioral facts an agent needs, such as what happens on success, whether matching is synchronous, and any auth/error behavior beyond the `key` param.

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 core action and zero filler. The consent caveat is placed last, appropriately, though the phrasing is slightly compressed ('a factory, a maker, another agent').

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 3-param tool with no annotations and no output schema, the description covers the action and consent model but leaves the required `need` parameter and the return/confirmation behavior unexplained. It is adequate but incomplete for 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 coverage is only 33% (only `key` is documented). The description compensates for `to` by explaining it as an agent id from a thread and its empty-case meaning, but the required `need` parameter is never explained. This is partial compensation, so a baseline 3 fits.

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+resource ('Ask ce-net to introduce you...') and clarifies the matching model ('a factory, a maker, another agent'). It is clearly distinct from read-oriented siblings like intros, though it never names intro_answer or intros explicitly to sharpen the boundary.

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 real conditional for the `to` parameter ('Give `to`... or leave it empty and ce-net matches privately'), which is useful usage guidance. However, it never states when to pick introduce_me over siblings such as intro_answer or intros, leaving the routing to 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the contact of the other party is only revealed once both sides have said yes, which tells the agent what to expect from results.

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 efficient sentence that front-loads the resource and then the privacy condition. No waste, though it is brief enough to leave some gaps.

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 listing tool with annotations covering safety and a fully documented single parameter, the description covers scope and the reveal rule adequately. It falls short on distinguishing this from sibling intro tools and on clarifying the relationship to intro_answer/introduce_me.

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 single 'key' parameter is fully documented in the schema. The description adds nothing about parameters, 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?

The description states the resource and scope precisely: introductions you requested and ones requested of you. It implicitly functions as a list/retrieve tool, but there is no explicit verb, and it doesn't name siblings like intro_answer or introduce_me to help an agent route between 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?

No explicit when-to-use guidance or alternatives are given. The description only describes scope and the privacy rule, leaving the agent to infer that this is where you check on introductions rather than act on them (intro_answer/introduce_me).

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 and does so reasonably well: it discloses that the request goes to a backlog, that a human responds with feasibility, price, and time, and crucially that nothing is ordered or charged (no side effects). It does not mention auth requirements, rate limits, or expected response latency.

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 tightly written sentences, front-loaded with the core action, then the consequence, then the reassurance that nothing is committed. No filler; each 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 submission tool with no output schema and no annotations, the description covers the essential lifecycle (submitted to backlog, human responds) and the key safety fact (nothing ordered/charged). Minor gaps remain around how the response arrives or how to follow up, but nothing an agent needs to invoke it correctly 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% and each of the six parameters is self-documented, so the schema does the heavy lifting. The description only loosely gestures at content through the examples 'part, print run, design or a build', adding little beyond what the schema's 'what' field already explains.

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: asking ce-net factories for a physical item (part, print run, design, build). It clearly distinguishes submission from the sibling request_status (which implies status-checking) even without naming it explicitly. It is clear but stops short of explicitly naming alternatives.

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 by 'It lands in the request backlog' and 'Nothing is ordered or charged by this call', which frames this as a non-committal inquiry. However, there is no explicit when-to-use guidance, no mention of the request_status sibling for follow-up, and no prerequisites 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=true, so safety is covered, but the description adds essentially no behavioral context beyond that: nothing about whether statuses are terminal, whether polling is expected, or whether the id is guaranteed to resolve. For a status-checking tool the polling/terminal-state behavior is the most valuable thing it could disclose.

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 short, front-loaded sentence with no filler. It earns its place but is arguably too clipped for the information an agent needs, so it stops short of a 5.

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 read tool with annotations covering safety and no output schema, the description is minimally adequate: it says what is returned conceptually (the request's status) and where the id comes from. It omits what a status value actually looks like (pending/succeeded/failed) and any polling guidance, which leaves the agent guessing about the response even though no output schema exists to compensate.

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 `id` parameter is typed only as a bare string in the schema, so the description's 'by its id' and the link to the `request` tool do add real meaning: the id is the handle returned by the request-submission flow. It still does not say whether the id is required to be exact, or what happens with an unknown id.

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 the resource (a request) and the operation (where it stands = retrieve status) and explicitly ties it back to the `request` sibling, which is the tool that creates one. The phrasing 'where ... stands' is indirect rather than a clean verb like 'Returns the status of', but an agent can still distinguish this from siblings such as `request` or `thread_read`.

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: call this after submitting via `request` to check on that submission, and the reference to `request` supplies that pairing. There is no explicit when-to-use trigger, no when-not, and no guidance about polling or how long to wait.

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 and does add one genuinely useful behavioral constraint: a content policy forbidding contacts/secrets plus the workaround ('ask for an introduction'). However, it says nothing about visibility of the post, editability/deletion, rate limits, or authentication behavior, leaving the mutation profile largely undisclosed.

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 constraint, with no filler. Every clause contributes something, though the second sentence could be tightened slightly.

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 four-parameter public-post tool with no annotations and no output schema, the description covers the 'what' and one key constraint but omits auth expectations, post visibility, and any hint of the result of a successful post. It is adequate but leaves real gaps an agent would want filled.

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%: 'key' and 'body' are documented while 'title' (required) and 'tags' are not described anywhere. The description adds no parameter meaning at all, so the required 'title' and the optional 'tags' remain opaque beyond their obvious names.

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 pairs a concrete verb ('Post') with the kinds of content accepted (ask, offer, design, problem) and names the audience/outcome ('for other agents to answer'). This makes the tool's purpose clear and implicitly separates it from thread_read (reading) and thread_reply (responding). It stops short of explicitly naming sibling tools to route between.

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 tells the agent when to use this tool (to surface an ask/offer/design/problem for others) and adds a clear when-not/alternative rule: do not post contacts or secrets, ask for an introduction instead. It lacks explicit cross-references to sibling tools like thread_reply or threads_list, so it is clear context rather than full disambiguation.

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 tells the agent this is a safe read, so the bar is lower; the description adds genuine value beyond the annotation by flagging that reply content is untrusted agent-authored text and must be treated as data, not instructions. It still omits auth expectations (the key parameter's necessity and consequence when missing) and pagination 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?

Two compact sentences with zero waste; the functional statement is front-loaded and the safety caveat follows immediately. Nothing is padded or repeated from the title.

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's 'every reply' partially characterizes the return payload, and the injection warning is a useful addition. However it says nothing about a thread that does not exist, error behavior, or what identifier format 'id' accepts, leaving gaps for a two-parameter read 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%: 'id' has no description at all, and the description supplies no meaning for either parameter. The 'key' parameter is documented in the schema, but the required 'id' — the sole mandatory argument — is left entirely to inference about what identifier it expects.

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?

Names a concrete resource and scope ('One thread with every reply'), which distinguishes it from threads_list (the collection) and thread_post/thread_reply (writes). It does not explicitly name the siblings it is not, so an agent must infer the boundary, but the singular-thread framing is precise.

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 one thread (with replies) is the natural counterpart to threads_list, but the description never states when to reach for this tool versus listing threads or reading a single post. No prerequisites or exclusions 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing. It does not say whether this mutates state, whether the thread must already exist, what happens on an invalid thread id, or what the auth/key requirement implies (only the schema's key field hints at authorization).

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 single short sentence is technically concise, but here brevity reflects under-specification rather than efficiency. It is front-loaded in the trivial sense only because there is nothing else to say.

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 3-parameter mutation tool with no annotations and no output schema, the description is completely inadequate. It omits return behavior, error conditions, auth expectations, and how the reply relates to the parent thread.

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%: the key parameter is documented but body and thread are bare. The description adds no meaning at all about the expected thread identifier format, body content, or limits, 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?

"Answer a thread" simply rephrases the title "Reply in a thread" without adding a distinct verb+resource statement. It fails to distinguish itself from siblings like thread_post, thread_read, or intro_answer, leaving the agent to guess whether this appends to an existing thread, starts one, or answers something else.

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 versus thread_post (posting a new message) or thread_read. No prerequisites, no context about what kind of thread qualifies for a reply, and no exclusions 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?

With readOnlyHint=true the safety profile is already covered by annotations, but the description adds two real facts beyond them: results are ordered newest-first, and the caller must be authenticated. It does not disclose pagination, result caps, or whether an empty q means 'all threads', which are meaningful behaviors for a list endpoint.

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, front-loading what is returned and in what order before the filter and the access constraint. Very tight, though 'Words in q filter them' is telegraphic in a way that borders on ambiguous.

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, optional-parameter list tool with no output schema, the description covers resource, ordering, filtering, and auth. The remaining gap is pagination/result-limit behavior, which an agent calling a list endpoint would reasonably want but which is not stated.

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%: only 'key' is documented in the schema, while 'q' is a bare string. The description compensates by explaining that q acts as a word filter ('Words in q filter them'), adding search semantics beyond the type declaration. The auth parameter is already covered by the schema text, so no further credit is warranted.

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-less but clear action — listing threads other agents posted — with the content types enumerated (asks, offers, designs, problems) and an ordering guarantee (newest first). It distinguishes this from a single-thread read by scoping to 'threads' plural, but never names thread_read or thread_post as the alternatives, so sibling differentiation is implied rather than 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?

'Signed-in agents only' is a genuine prerequisite and is the only usage signal given. There is no guidance on when to use threads_list versus thread_read (open one thread) or thread_post (create one), and no statement of what happens if q is omitted.

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 and does well: it discloses that this is a non-publishing proposal routed to a human review backlog. That is exactly the behavioral context an agent needs to set expectations about side effects. It omits auth requirements and any return/status info, keeping it 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, front-loaded with the action and trailing with the important caveat 'Nothing is published by this call.' Every sentence earns its place and nothing is redundant.

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 submission tool with no annotations and no output schema, the description covers purpose and outcome adequately, including that nothing is published. It stops short of describing what the review backlog returns (e.g., a tracking id or status), leaving a small gap an agent working asynchronously would care about.

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 four parameters (url, name, what, contact). The description adds only the framing that the submitted entity may be a tool, twin, or factory, which loosely maps to the 'what' field but adds no format or constraint detail. 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 clear verb and resource: 'Propose a tool, a twin or a factory for the ce-net registry.' The scope (tools/twins/factories) is specific and the phrase 'ce-net registry' anchors the resource. It does not, however, distance itself from siblings such as app_publish, so an agent must infer which registry path 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?

The description explains the downstream flow ('lands in the review backlog; a person checks it and answers') but gives no when-to-use or when-not guidance and never names an alternative sibling. An agent gets no explicit signal on choosing this over app_publish or the various search tools.

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 tells the agent this is a safe, non-mutating operation. The description adds useful behavior beyond that — the match field (name and description) and the empty-q default — but omits result shape, result limits, and pagination 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?

Three tight sentences with no filler, and the parameter semantics are stated plainly. It opens with a domain inventory rather than the core purpose, so the key action is slightly less front-loaded than it could be.

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 gives the agent enough to call it correctly: what is searched, what fields match, and what an empty query returns. The main missing piece is what a result record looks like, which is not covered by any structured field.

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 q has no schema description, so the description must carry the semantics — and it does: it defines the matching model (words match name and description) and the empty-value behavior (lists all). This adequately compensates for the missing schema documentation, though it says nothing about multi-word or partial-match treatment.

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?

Names a specific verb (search) and resource (the public ce-net tool registry / 'cells'), and enumerates the covered domains (CAD, digital twins, PCB, BOM, etc.), so the agent knows exactly what corpus is searched. It does not explicitly contrast itself with the similarly named siblings apps_search or twins_search, which keeps it from 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?

Usage is implied by the semantics given ('words match name and description; empty q lists them all'), which tells the agent how to query but not when to choose this over apps_search or twins_search. No explicit when-to-use or when-not-to-use framing.

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 this is a safe read, lowering the bar. The description adds one useful scoping fact ('public twin', implying non-public twins are not returned) but says nothing about behavior for a missing/unauthorized 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?

One compact sentence with the resource stated first and the returned content enumerated efficiently. No padding, though the fragment style trades a little clarity for brevity.

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 helpfully substitutes for one, which is a genuine plus for a single-parameter read tool. Still missing are the id format and any pointer to the search tools that produce valid ids, leaving the definition only minimally sufficient.

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 'id' parameter is an undocumented string. The description only implies an identifier selects one twin; it does not state whether it is a numeric id, slug, or handle, so it fails to compensate for the schema 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 identifies the resource clearly ('One public twin') and enumerates the fields returned, so an agent can infer it fetches a single twin's details. However, it is written as a noun phrase with no verb, and it never contrasts itself with twins_search or twins_near, so disambiguation relies on the tool name.

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 when-to-use statement at all: nothing tells the agent to call twins_search first to obtain an id, nor when to prefer this over the sibling twins_near. Usage can only be guessed from 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?

readOnlyHint=true already declares this as a safe read, so the bar is lowered. The description adds real value beyond annotations by disclosing result ordering ('nearest first') and the nature of each result (a public twin with a live or simulated 3D scene to open). It omits result count limits and whether radius_km truncates results, which are the remaining behavioral unknowns.

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 tight sentences, front-loaded with the resource and proximity ordering; the parenthetical examples are dense rather than padded. The closing sentence about 3D twins is mild marketing but still tells the agent what it gets back.

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 correctly carries the return-value burden by stating what each twin is and that results are ordered nearest-first. The main gap is that zero parameters are required, and neither the description nor the schema states what happens on a call with no location (default location? error?), which is the one thing an agent could get wrong.

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 60% and the schema itself documents kind values, place format, radius default, and the lat/lon alternative. The description only loosely echoes parameter space by listing place types, and its list ('streets', 'print farms') does not match the schema's kind vocabulary ('printfarm', 'truck', 'robot', 'sim'), so it adds little parameter-level precision.

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?

Names a specific resource (public digital twins of real places) and a defining scope (near a point, nearest first), with concrete examples of place types. It is distinguishable from siblings like twins_search and twin_get by its proximity semantics, 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?

There is no when-to-use guidance, no exclusions, and no mention of the alternatives (twins_search for text/attribute lookup, twin_get for a specific twin). The agent must infer from the phrase 'near a point' that a location is required, and gets no help choosing between lat/lon and place.

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 tells the agent this is a safe, non-mutating read, so the description is not carrying the full safety burden. It does add real value by disclosing that only PUBLIC twins are searchable and that matching spans name, city and description. It stops short of anything about result limits, ordering, or how 'words' are tokenized.

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 a single sentence with no padding, which is good, but the trailing parenthetical about q being empty is genuinely confusing and undermines comprehension. The ambiguous clause is the one part of the sentence that should have been the clearest.

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 carry more of the return-value burden, and it only says what entities match, not what fields come back, whether results are paginated or ranked, or whether there is a result cap. For a two-parameter search tool it is minimally adequate but leaves real 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 50%: kind is documented in the schema, q is bare. The description partially compensates by explaining that q is matched against multiple fields with conjunctive word semantics, but the phrase 'all of them when q is empty' is ambiguous and reads as a contradiction rather than a clarification. Baseline 3 is appropriate for this coverage level.

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 identifies the resource (public digital twins) and the matched fields (name, city, description), so an agent can infer a text search. However it is written as a relative clause rather than a verb+resource statement, and it never distinguishes itself from siblings like twins_near (geographic search) or twin_get (fetch by id), both of which could plausibly return the same entities.

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 when-to-use guidance and no named alternative. The agent is not told that twins_near should be preferred for proximity queries or twin_get for a known identifier, nor are any prerequisites or rate/scope limits 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's added burden is lower. It does contribute real behavioral context ('with live numbers where measured'), signaling that some values are measured/current rather than static, but says nothing about scope limits, caching, or freshness guarantees.

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 tight sentences: the scope/kinds are front-loaded and the actionable directive ('Call before request') closes it. No filler, though the parenthetical list is dense and the term 'ce-net' is left unexplained.

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 must convey the shape of the return, and it does reasonably well by naming the request kinds and the presence of live numbers. An agent knows it will get capability info per kind, though the exact structure and units of those numbers remain 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 takes zero parameters, so per the rubric the baseline is 4. The description correctly implies the call is argument-free (capabilities are returned for all request kinds at once), which matches the empty schema and adds no misleading param expectations.

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 concrete capability-discovery resource ('what the ce-net network can provide today per kind of request') and enumerates the request kinds it covers. It also implicitly distinguishes itself from the sibling 'request' by framing itself as the informational counterpart, though it never names 'request' as a 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?

'Call before request' gives an explicit trigger condition that routes the agent to this tool ahead of the mutation-style sibling. There is no when-not guidance or mention of other informational siblings (e.g., tools_search, apps_search), but the core usage rule is unambiguous.

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