viridisos

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

No annotations are provided, so the burden is on the description. It only states the action without disclosing side effects, authorization needs, or behavioral traits like whether it is mutating or whether the envelope is stored.

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?

Single sentence with no filler. All words are necessary and front-load the purpose.

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?

Despite having an output schema, the description fails to explain what the envelope contains or any behavioral details. The event parameter is undefined, leaving significant gaps for a tool that issues a complex object.

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 has 0% description coverage for the single parameter 'event', which is an opaque object with additionalProperties true. The description adds no meaning beyond what the schema provides.

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 'Issue' and identifies the resource as a 'mark-stamped agent-attestation envelope', with the context 'under the shared trust root'. It clearly distinguishes from siblings like viridis_certify and viridis_verify_mark.

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 on when to use this tool versus alternatives. The description lacks prerequisites, context, or 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?

The description does not disclose side effects, authorization needs, or whether the operation is read-only. Without annotations, this omission leaves the agent guessing about the tool's behavior beyond the derivation itself.

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, concise and front-loaded with the main action. However, it sacrifices necessary detail for brevity, earning a 4 rather than 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?

While an output schema exists to cover return values, the description omits prerequisites, constraints, and typical usage scenarios. For a tool with no annotations and undocumented parameters, this is insufficient.

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

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

With 0% schema description coverage, the description must explain parameters but does not. 'agent_id' and 'pubkey' are only named; no format, constraints, or examples are provided, leaving their meaning ambiguous.

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 verb 'derive' and the resource 'canonical did:viridis identity', specifying the agent type (fleet R1 formula) and context (under the shared root). It distinguishes from siblings by focusing on identity derivation, though it could be more explicit about its unique role.

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 on when to use this tool versus alternatives like viridis_agent_attestation or viridis_verify_mark. The description implies it's for deriving identities, but fails to clarify prerequisites or conditions.

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 one important behavioral trait: the tool errors if the module's backing theorem is not gate-passed. However, it does not mention idempotency, side effects, or cost. The disclosure is minimal but provides a key constraint.

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, focused sentence that front-loads the core action and error condition. It is concise and avoids fluff, though it could be slightly more structured with bullet points for clarity.

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 3 required parameters, a nested inputs object, and an output schema, the description is incomplete. It does not explain the output or the structure of the inputs object. The agent would need to guess or consult other sources.

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%, so description must compensate. The description only adds minimal context for 'subject' (parcel/portfolio). Inputs and module_id are unexplained. The nested inputs object is not described, leaving the agent without guidance on structure.

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 verb 'Certify', the resource (subject), and the outcome (certificate). It also specifies an error condition (blocked if theorem not gate-passed), which helps differentiate from sibling tools like viridis_certify_envelope.

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 on when to use this tool vs alternatives. The description does not mention prerequisites, when not to use it, or how it compares to related tools like viridis_certify_envelope or viridis_verify_mark.

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

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

No annotations provided, so the description must fully disclose behavior. It does not mention side effects (e.g., state changes), authorization needs, or whether it is safe to call multiple times.

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?

Single sentence, but lacks structure. Could be more informative without being verbose.

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 three required parameters including a nested object, and with an output schema not described, the description is insufficient for an agent to use correctly without additional 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?

With 0% schema description coverage, the description must add meaning for parameters. It does not explain 'module_id', 'subject', or 'inputs' at all.

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

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

Description states it certifies and returns a mark envelope, with a specific profile 'conservation-claim'. This is specific about verb and resource, but does not explicitly differentiate from sibling 'viridis_certify'.

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 on when to use this tool versus alternatives like 'viridis_certify'. No context on prerequisites or typical workflow.

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 disclose behavioral traits. It states 'Compute' but does not clarify if this is a read-only calculation or if it triggers side effects like creating a record. The description implies a pure computation but lacks explicit confirmation of safety or required auth.

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, clear sentence that conveys the core purpose without extraneous words. It is appropriately front-loaded, immediately stating the action and result.

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 schema descriptions, missing annotations, and a complex domain (margin + card cost), the description is too brief. It does not define what 'the take' refers to, what payee_tier values are, or the unit of amount_minor. The existence of an output schema does not compensate for these 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?

The input schema has 0% description coverage, and the tool description does not mention or explain the parameters 'amount_minor' or 'payee_tier'. There is no hint about expected values, units, or formatting, leaving the agent without necessary context to populate these fields correctly.

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 computes a 'unified Viridis protocol margin (the take) + pass-through card cost' for a settlement. This verb+resource combination is specific and distinguishes it from sibling tools like viridis_certify or viridis_verify_mark, which focus on certification and verification.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It lacks context about prerequisites, such as whether a settlement must exist first, or when to prefer compute_toll over other tools. No explicit exclusions or alternative suggestions 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 no annotations, the description is the sole source of behavioral info. It mentions the output state (LIVE/BLOCKED) and a cryptic reference to 'A-1 against the live canon', but does not disclose authentication needs, rate limits, or side effects. For a read-only list tool, the transparency is adequate but lacks detail.

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 efficiently conveys the purpose and key detail (state). It is front-loaded with the verb and resource, with no unnecessary words.

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

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

Given no parameters and the existence of an output schema, the description is partially complete. It explains the tool lists modules and their state, but the 'A-1 against the live canon' jargon is unclear. More context about what constitutes a module or the meaning of the state would improve completeness.

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

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

There are no parameters, so schema coverage is 100%. The description adds value by indicating what the output contains (module names and their state), which is not evident from the empty 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 clearly states the verb 'List' and the resource 'ViridisOS modules', and specifies that it returns their state (LIVE/BLOCKED). It effectively distinguishes from sibling tools like viridis_bind_did or viridis_certify which perform different operations.

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

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

The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only states what the tool does without context.

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 disclose behavioral traits. It states 'Verify' (suggesting read-only) but does not mention outcomes of verification (success/failure), side effects, or authorization needs. This leaves significant behavioral 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 a single sentence with no extraneous words. It is front-loaded with the key action and resource, making it immediately useful. No waste.

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

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

Given the tool's complexity (2 parameters, output schema), the description is too brief. It does not explain the output, prerequisites (e.g., trust root setup), or the role of the optional profile. An output schema exists but is not referenced, limiting completeness.

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

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

With 0% schema description coverage, the description adds meaning only for the envelope parameter (it must be a 'Certified by ViridisOS' envelope). The optional 'profile' parameter is unexplained, leaving its role ambiguous.

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 action ('Verify'), the resource ('a Certified by ViridisOS envelope'), and the method ('against the shared trust root'). This distinguishes it from sibling tools like viridis_certify (creation) and viridis_agent_attestation (attestation).

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 verifying certified envelopes but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The purpose is clear, but context for decision-making is missing.

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