OnlyHarness Registry

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

With no annotations provided, the description carries the full burden. It discloses what the tool returns (manifest, trust signals, example, file list), but does not mention potential side effects, authentication requirements, or error behavior (e.g., what happens if the harness does not exist).

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 succinct sentence that front-loads the purpose. Every word is necessary; no extraneous 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?

The tool has no output schema, so the description must explain return values. It lists four components but does not describe their structure or any nesting. With only two parameters (one well-described) and moderate complexity, the description is adequate but leaves gaps about the output format.

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 the 'name' parameter has a description; 'owner' has only a default. The tool description does not add any additional meaning or clarify the parameters beyond what the schema provides. Given moderate coverage, the description should compensate but does not.

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 'Return manifest, trust signals, example and file list for one harness.' This clearly specifies the verb (return) and the resource (specific components of a single harness), differentiating it from sibling tools like search_harnesses or publish_markdown_to_harness.

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

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

The description implies usage when needing detailed information about a specific harness, but it lacks explicit guidance on when to use this tool versus siblings (e.g., when not to use it or what alternatives exist).

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 exist, so the description must bear transparency. It states the action and that the scaffold is 'unverified', but does not disclose side effects (e.g., whether it saves or returns the scaffold), authentication details beyond token requirement, or error 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 sentences with front-loaded action verb and prerequisite. Concise but omits crucial parameter details, which reduces its utility despite 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 and moderate complexity (auth required, conversion process), the description fails to explain the result format, potential errors, or lifecycle of the scaffold. The 2 parameters are undocumented, leaving significant 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 0%, and the description provides no information about the 'name' or 'markdown' parameters. The agent has no guidance on what values to provide, hurting selection and invocation accuracy.

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 converts markdown into an unverified harness scaffold, using a specific verb and resource. It distinguishes from sibling tools like pull_harness or search_harnesses by focusing on creation from markdown.

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 mentions a prerequisite (Bearer token) but provides no guidance on when to use this tool versus alternatives like pull_harness or search_harnesses. The usage context is implied but not explicitly 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 full burden. It discloses a conditional behavior for paid harnesses (return payment requirements unless token entitled), which adds transparency. However, it omits other behavioral traits like error states, file size limits, or whether the action is destructive.

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 efficient sentences: first states the core purpose, second adds an important nuance. No wasted words, front-loaded.

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 with 3 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain parameter meanings, output format, or full behavior beyond the paid harness condition.

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%, yet the description adds no information about the three parameters (name, owner, version). It only vaguely implies the harness name is relevant. This is a critical 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 clearly states the tool returns archive files for a harness, using a specific verb 'Return' and resource 'archive files for a harness'. It distinguishes from siblings like harness_detail (details vs archives) and pull_instructions (instructions vs archives).

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 harness archive files but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it. The nuance about paid harnesses hints at a condition but does not cover exclusions.

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, and the description does not disclose any behavioral traits such as whether the tool is read-only or has side effects. Since it returns commands, it is likely safe, but this is not stated.

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 concise at one sentence but lacks necessary detail. It is not front-loaded with key info, and while efficient, it is under-specified for the tool's complexity.

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 lack of annotations and output schema, the description is severely incomplete. It does not explain what a 'harness' is, the role of parameters, or the format of the returned commands.

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 tool description does not mention the parameters 'name' or 'owner'. No meaning is added beyond the schema, leaving the agent uninformed about their purpose.

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 returns CLI and HTTP commands for pulling a harness, distinguishing it from sibling 'pull_harness' which likely performs the actual pull. The verb 'return' and resource 'commands' are specific.

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 guidance is provided on when to use this tool versus alternatives like 'pull_harness'. The description does not mention prerequisites or context for usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the returned fields but omits critical details: whether the operation is read-only, requires authentication, or handles errors (e.g., invalid ID). The lack of such context makes it harder for an agent to anticipate side effects or constraints.

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 concise sentence that front-loads the key information. It is efficient but could be slightly more structured (e.g., listing the return fields separately). 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?

For a simple one-parameter tool with no output schema and no annotations, the description is minimally adequate. It states what the tool returns, but does not explain the format of the ID or provide examples. Given the low complexity, it is mostly complete but lacks some context for confident usage.

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

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

The input schema has 100% coverage, so the schema already documents the single parameter 'id' with a clear description. The tool description adds no extra meaning beyond what the schema provides. Thus, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns 'provenance, trust, popularity and actions for one mixed resource.' The verb 'Return' and specific fields make the purpose unambiguous. It is distinct from siblings like 'harness_detail' (which returns harness-specific info) and 'search_resources' (which searches, not retrieves a single resource).

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 guidance is provided on when to use this tool versus alternatives. For example, it does not mention that 'harness_detail' should be used for harnesses, nor does it describe prerequisites like needing a valid resource ID. The description only implies usage for a single resource by stating 'for one mixed resource.'

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 bears full responsibility for behavioral disclosure. It reveals that the tool returns a value and avoids pulling non-harness archive files, suggesting a read-only, safe operation. However, it omits critical details such as whether the tool modifies any state, requires authentication, or has side effects. The description is too sparse to adequately inform the agent of behavioral traits.

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 front-loads the core purpose ('Return the best safe next action') and then adds a qualifying constraint. Every word earns its place; there is no fluff.

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

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

With no output schema, the description should explain what the return value looks like or what constitutes a 'safe next action', but it does not. It also fails to define 'mixed resource' or indicate the format of the response. The description is incomplete for an agent to fully understand the tool's function.

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% for the single 'id' parameter, with the schema already providing an example. The description does not add any additional semantics or usage details for the parameter, so it meets 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 returns the best safe next action for a mixed resource, using a specific verb and resource. It also distinguishes itself by specifying it does not try to pull non-harness archive files, differentiating it from siblings like pull_harness. However, terms like 'mixed resource' and 'safe next action' are somewhat jargon-y and may not be universally 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?

The description implies usage when one needs a safe action without pulling archive files, but it does not explicitly state when to use this tool versus its siblings (e.g., pull_instructions, resource_detail). No direct alternatives or exclusions are mentioned, so the guidance is only implied.

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 does not disclose whether the tool is read-only, requires authentication, has rate limits, or any side effects. The description only states what it searches, not how it behaves.

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 sentence that is front-loaded with the essential action and resource. Every word adds meaning, with no redundant or filler content.

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

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

For a simple one-parameter tool with no output schema or annotations, the description covers the core purpose and target resources. However, it omits details such as query behavior (e.g., fuzzy search, multiple terms) and returned content structure, leaving gaps for an agent.

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

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

Schema description coverage is 0%, and the description does not explain the 'query' parameter beyond its name. It does not clarify accepted formats, default behavior (empty string), or any constraints, leaving the agent without guidance beyond the parameter name.

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 /llms.txt and agent guidance for specific categories (API, CLI, MCP, safety instructions), providing a specific verb ('search'), resource, and scope. It distinguishes from sibling tools like 'search_harnesses' which targets different resources.

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

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

The description implies usage when needing to find instructions from the specified sources, but does not explicitly state when to use this tool versus alternatives like 'search_harnesses' or when not to use it (e.g., for non-doc searches).

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 present, so the description must fully disclose behavior. It only states the search scope and fields, but lacks details about result ordering, pagination, partial matching, required permissions, or any side effects. This is insufficient for a search tool.

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

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

The description is a single sentence, which is concise. However, it lacks structure (e.g., bullet points) that could improve readability and clarity for an AI 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 simple search tool with 2 parameters and no output schema, the description is adequate but incomplete. It omits details about result format, empty results behavior, and sorting. A more complete description would include typical search tool characteristics.

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

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

The description adds context about which fields the query can match (task, job, title, summary, tag), supplementing the schema's basic description. However, it does not address the 'limit' parameter's behavior (e.g., pagination), and schema coverage is 50% with no nested objects.

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 explicitly states the tool searches the OnlyHarness registry by specific fields (task, job, title, summary, or tag). This clearly distinguishes it from siblings like harness_detail (for single harness details) and pull_harness (for retrieval).

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 what can be searched but does not contrast with sibling tools or provide guidance on when to use this vs. alternatives. No when-not-to-use or prerequisite information is 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 must bear the full burden. It only lists the types of resources searched, with no disclosure of behavioral traits such as pagination, ordering, authentication requirements, or rate limits. This is insufficient for a complex search tool.

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

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

The description is a single sentence that front-loads the core action ('Search mixed source-aware resources') and enumerates the resource types. It is efficient and avoids unnecessary words, though it could benefit from additional structure.

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 has 5 parameters and no output schema or annotations, the description is too sparse. It does not explain search behavior, result format, or any constraints like maximum limit or required scopes. An agent would lack critical context for reliable 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?

The input schema has 80% description coverage, so the schema already documents most parameters. The description does not add new parameter meaning beyond listing resource types. It does not explain how parameters like 'q' vs 'query' differ or how 'worksWith' filters work.

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 it searches 'mixed source-aware resources' and lists specific types like harnesses, skills, plugins, etc. This distinguishes it from sibling tools such as search_docs or search_harnesses which have narrower scope. However, the phrase 'source-aware' is slightly ambiguous.

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 guidance is provided on when to use this tool versus alternatives. While the description implies it covers many resource types, it does not mention when to prefer a more specific sibling tool like search_docs for documentation.

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