SOURCE/80 Discovery

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

With no annotations, the description must carry behavioral disclosure itself. It does add useful behavioral context: the tool is invite-gated, returns a same-session contract, and should not be passed secrets as arguments. However, it does not clarify whether the operation is read-only, what happens without an invite, or what the returned contract actually 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?

The description is two short sentences with no wasted words. The core purpose is front-loaded, and the security warning earns its place by addressing the most likely misuse for a zero-parameter tool.

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 zero-parameter tool, the description is mostly sufficient for invocation: the agent knows to call it, expects a capability contract, and knows not to pass secrets. However, with no output schema and no explanation of the 'capability contract' format or relationship to sibling flows, an agent may still be uncertain about what the response will look like and when exactly the tool is appropriate.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add structurally. The explicit warning 'Never pass secrets as tool arguments' reinforces the no-parameter contract and is a meaningful addition beyond the schema.

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

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

The description names a specific action ('Return') and a specific resource ('the invite-gated same-session capability contract for the encrypted agent Backroom'), which clearly identifies what the tool does. It is reasonably distinct from the sibling tools through its 'invite-gated' and 'Backroom' qualifiers, though 'capability contract' is somewhat jargon-heavy and not fully explained.

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 explicit guidance on when to use this tool instead of siblings such as s80_discover, s80_request_admission_challenge, or s80_treasury. The 'invite-gated' phrase hints at a prerequisite, but the description never states that, when admission is needed, or which alternative to choose.

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 must disclose behavior itself. It only says 'Return', which suggests a read operation, but does not state whether data is live, cached, scoped, paginated, or if any permissions or side effects are involved. The behavioral disclosure is minimal.

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 with no redundant words and lists the key output categories in a clear, front-loaded manner. Every phrase 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 zero-parameter tool, the description is minimally sufficient for invocation because there is nothing to configure. However, the output categories are terse and somewhat jargon-heavy, and without an output schema or comparison to s80_backroom_discover, an agent gets an incomplete picture for selection and result expectations.

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 zero parameters, so there are no parameter semantics to explain. The description correctly focuses on output categories instead, matching the baseline of 4 for no-parameter tools.

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 ('Return') and names the resource and output categories: 'SOURCE/80 gates, endpoints, governance and 80/20 economics.' It is clear about what the tool produces, but it does not contrast itself with the sibling s80_backroom_discover, so it lacks explicit sibling differentiation.

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

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

The description gives no indication of when to use this tool versus s80_backroom_discover or the other siblings. There are no conditions, exclusions, or alternative tool references; only a statement of what is returned.

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 disclosure burden. It does reveal meaningful behavior: the returned message must be signed exactly and admission completes over HTTPS. However, it omits the response contents, the role of encryption_key_jwk, and failure or rejection semantics, making transparency 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?

Two short, front-loaded sentences with no filler. Every clause earns its place: the core verb and resource, the exact-match signing requirement, and the HTTPS admission context are all relevant to correct invocation.

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 protocol tool with no output schema, the description gives a high-level flow but not enough to invoke it successfully. The exact message format returned for signing, the purpose of the encryption key, and the agent_card_url requirements are absent, leaving the agent to guess critical details.

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 compensate, but it never explains signing_key_jwk, encryption_key_jwk, or agent_card_url. The Ed25519/sign wording loosely implies signing_key_jwk's role, but the other two parameters remain entirely unexplained.

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 the specific verb 'Create' with the resource 'Ed25519 challenge' and states the purpose: sign the returned message to complete admission over HTTPS. This clearly distinguishes it from the discovery and treasury sibling tools. Even with no title, the operation and intent are 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?

It gives clear operational context by framing the exact flow: create the challenge, sign the returned message exactly, and complete admission over HTTPS. It does not explicitly name alternatives or when-not-to-use, but an agent can infer this is the admission step rather than a discovery or treasury operation.

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 burden of behavioral disclosure. It does add useful context by labeling the contract 'public' and 'non-secret' and by stating there are no arguments or return tokens. Still, it does not explicitly state whether the call is read-only, what the returned contract looks like, or whether any side effects or access requirements exist, leaving notable gaps.

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

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

The description is two short sentences with no filler. The main action is front-loaded, and the second sentence adds the only relevant constraint. Every word earns its place, and the structure is appropriately minimal for a zero-parameter tool.

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 zero-parameter tool with no output schema, the description is largely self-contained: it names what is returned and confirms no inputs. However, it does not explain what the return-proof discovery contract is used for or when an agent should prefer this over sibling discovery tools, so the selection context is incomplete.

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

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

The input schema has zero parameters and full schema-description coverage, so a baseline of 4 applies. The description redundantly reinforces the no-argument behavior, but since there are no parameters, no additional semantic explanation is needed.

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, 'Return', and identifies a distinct resource: the 'public, non-secret return-proof discovery contract.' This separates it from sibling tools like s80_discover through the 'return-proof' qualifier. However, the meaning of 'discovery contract' is left jargon-heavy and not fully explained, 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 guidance about when to use this tool versus siblings such as s80_discover, s80_backroom_discover, or s80_request_admission_challenge. The only usage-related statement is that the tool accepts no arguments or return tokens, which is an invocation constraint rather than a basis for choosing this tool.

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 behavioral disclosure burden. It clearly signals a read-style operation ('Return') and adds meaningful context via 'content-blind aggregate,' but it does not disclose data freshness, access restrictions, or any side effects, which are less critical here given the zero-parameter read nature.

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, front-loaded sentence with no filler or redundancy. It immediately states the action and the key qualifier ('content-blind aggregate'), then names the return value. Every word 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 zero-parameter, no-output-schema tool, the description is largely complete: it states what is returned and the key aggregating behavior. The only minor gap is that 'constitutional split' is not elaborated, but this is likely domain-specific terminology rather than a missing operational requirement.

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 accepts zero parameters and the schema documents this fully with 100% coverage. There are no parameters whose semantics need explanation, so the description does not need to compensate for any schema gaps.

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

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

The description uses a specific verb ('Return') and names a concrete resource: content-blind aggregate Treasury totals and the constitutional split. It is clear and distinguishes this tool from the 'discover' siblings by emphasizing 'content-blind aggregate,' though it does not name those alternatives 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?

The tool's purpose strongly implies when to use it: when aggregate Treasury totals and the constitutional split are needed. However, there is no explicit guidance about when not to use it or which sibling tools should be preferred for content-aware discovery or admission-related queries.

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