ENYAL by Greenland AI

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful 'structure only, no content' scoping of what comes back, but says nothing about the shape of that structure (fields vs. edges) or what happens when name_hash matches nothing.

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 lookup key and scope, with zero filler. Every clause carries information the agent needs to invoke the call correctly.

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-key read tool with full schema coverage and rich annotations, the description covers key, scope and the read-only nature adequately; no output schema exists, so return values need not be described. The only residual gap is that 'STRUCTURE' is never defined (which fields or relations are returned), which an agent may want in order to use the result.

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 description's parenthetical gloss on name_hash ('SHA-256 of the normalised name') essentially restates the schema text verbatim. The node_id compatibility caveat is likewise documented in the schema, so the description adds no meaning beyond structured fields.

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 ('Get'), a specific resource ('one entity's STRUCTURE'), and the exact lookup key ('by name_hash (SHA-256 of the normalised name)'). The trailing 'No content.' explicitly differentiates it from the sibling get_entity_content, so an agent can choose correctly without opening either schema.

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 'No content' constraint clearly scopes when this tool applies versus get_entity_content, and the name_hash requirement sets the precondition for a meaningful lookup. It stops short of naming the alternative tool explicitly, so the routing is strongly implied rather than spelled out.

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 establish readOnly/idempotent/non-destructive, but the description adds two things they don't: the returned content is decrypted, and the call fails with 403 without content scope. That is meaningful behavioral context beyond the structured hints, though nothing is said about return shape or size/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?

Two compact sentences with the identifier semantics and the scope constraint front-loaded and no filler. Every clause carries information an agent needs.

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 tool with full annotation coverage and no output schema, the description covers the identifier, the decryption semantics, and the authorization failure mode — the main things needed to call it correctly. It is only thin on relating itself to the sibling content/entity tools.

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

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

Schema coverage is 100% and the schema already defines name_hash as the SHA-256 hex of the normalised name and marks node_id as unused, so the description's restatement of name_hash adds no new syntax or constraints. Baseline 3 when the schema does all the 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?

Names a specific verb and resource — get one entity's decrypted content — plus the key identifier (name_hash). The DECRYPTED emphasis hints at the distinction from plain-text siblings, but it never explicitly contrasts itself with get_entity or get_node_content, so an agent must infer which of the content tools to pick.

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

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

It states one real prerequisite (content scope required, 403 otherwise), which is genuine usage context. However, it gives no when-not guidance and never names an alternative tool, so the choice between get_entity_content, get_entity, and get_node_content is left 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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the content is DECRYPTED, a content scope is required or a 403 results, and neighbour depth is clamped to 0-5. It stops short of describing the return payload.

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, front-loaded sentences with no filler; the decrypted-content purpose and the neighbour expansion lead. It leans on 'Same plan schema as the structure tools', which is terse but contextually efficient.

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, two-parameter tool with full schema coverage and no output schema, the description covers scope, auth requirement, and depth behavior, but says nothing about the shape of the returned content or how the plan schema maps to results. Adequate but with a clear gap.

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 both parameters are already documented, including the name_hash purpose and the depth clamp/default. The description reinforces name_hash usage and the depth default but adds no syntax or format detail beyond the schema; 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 ('Get a node's DECRYPTED content by name_hash') plus the extra scope ('PLUS its connected nodes' content'). 'Same plan schema as the structure tools' signals it is the content counterpart to the structure tools, but no sibling is named outright, so an agent must infer the get_node vs get_node_content split from the pattern.

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 one concrete usage constraint ('Content scope required (403)') and implies this is the decrypted-content variant, but never states when to choose it over get_node or the sibling *_content tools. Usage is implied rather than explicit.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the key behavioral fact that no content payload is returned, but says nothing about ordering ties, result size, or pagination.

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 terse sentences, zero filler, with the ordering guarantee and the 'no content' distinction 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?

With no output schema, the description compensates by conveying the return shape ('structure view', 'no content'). Complete enough for a read-only, zero-required-parameter query tool, though it omits ordering tie-breaking behavior.

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 are already documented in the schema. The description merely restates the filter dimensions (node_type, ISO8601 date range) without adding format or default semantics, so 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 resource (temporally-ordered structure view) with its ordering guarantee and filter scope. The trailing "No content" cleanly signals how it differs from the sibling get_timeline_content, though the phrasing is telegraphic rather than a clean verb+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?

Usage is only implied: 'optionally filtered by node_type and an ISO8601 date range' plus the 'No content' clause hints that get_timeline_content is the alternative for content, but no explicit when/when-not guidance or named alternative 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?

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine value beyond them: the payload is DECRYPTED, it shares get_timeline's plan schema, and a missing content scope returns 403.

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 compact, front-loaded sentences with no filler; the primary capability is stated first and each clause carries information (scope, filter dimensions, schema compatibility, auth requirement).

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 compensates by naming the return shape ('Same plan schema as get_timeline') and the auth precondition. What an agent needs to call it correctly is essentially present, with only minor gaps around the sibling content tools.

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 three optional filters (node_type, valid_to_before, valid_from_after) are fully documented in the schema itself. The description only restates the node_type and date-range dimensions without adding syntax or semantics beyond the structured fields.

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: a temporally-ordered decrypted content view, filterable by node_type and ISO8601 range. It differentiates the content variant from its structural sibling get_timeline ('Same plan schema as get_timeline'), though it doesn't explicitly contrast with get_node_content or get_entity_content.

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 rather than stated: the 'content view' framing and the 'Content scope required (403 otherwise)' note hint at when the tool is usable, but there is no explicit when-to-use / when-not-to-use guidance versus get_timeline or get_node_content.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds non-obvious behavior beyond that: results are hashed identifiers only, account scope is server-enforced and not settable, and it enumerates the returned fields (node_type, name_hash, relationships, chunk_ids, timestamps). It stops short of describing pagination or result-size 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?

Front-loaded purpose in the first two sentences, then a compact plan skeleton, then the enumerated vocabularies, then the scope caveat. The code block earns its length because the schema points readers to it for enum values.

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 nested-plan query tool with no output schema, the description supplies the return field list, the full allowed-value vocabularies, numeric bounds, and the server-enforced scope constraint. Nothing an agent needs in order to construct a valid plan is left unstated.

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

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

The schema explicitly defers to the description for allowed values, and the description delivers them: the full node_type vocabulary, the ten valid relationship values, the direction enum, ISO 8601 temporal bounds, limit <= 200, and include_neighbours_depth 0-5. With additionalProperties true and zero enums in the schema itself, this text is the authoritative source of parameter meaning rather than a restatement.

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 ("Execute a structured query plan over your encrypted knowledge graph") and immediately declares the output scope ("STRUCTURE ONLY ... never content"), which is exactly what separates it from the sibling query_memory_content. An agent can distinguish it from the *content tools without opening a schema.

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 phrase "Returns STRUCTURE ONLY ... never content" functions as an implicit when-to-use/when-not rule and routes the agent toward the content-returning sibling for actual text. It also states an operational precondition the caller cannot override ("Account scope is enforced server-side; it cannot be set from the plan"), but it never names the alternative tool explicitly.

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?

On top of annotations that already cover the safety profile (readOnly, idempotent, non-destructive), it discloses concrete behavioral facts: a memory:read:content-scoped token is required, a structure-only token is rejected with 403 by ENYAL, and account scope is enforced server-side and cannot be overridden from the plan. These are exactly the operational details an agent needs and that annotations cannot express.

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, front-loaded with the primary action and return content, followed by the schema relationship and the auth constraint. No filler; every sentence carries distinct information.

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

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

With no output schema, the description compensates by naming what is returned (node names, summaries, properties, edge evidence + endpoints), and it covers the key auth/scope constraints for a nested-plan tool. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, and the plan parameter already carries a detailed inline description of its filters, bounds, and limit. The description adds no per-parameter detail and only notes the plan schema is shared with query_memory, so the baseline 3 for a well-documented schema 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 (execute a structured query plan) and precisely what it returns: decrypted node names, summaries, properties, and edge evidence with endpoint names. It explicitly distinguishes itself from query_memory by noting the 'SAME plan schema' but decrypted-content behavior, so an agent can tell the two apart without opening a schema.

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?

Clearly signals the differentiator versus query_memory (decrypted content vs structure-only) and states the prerequisite token scope. It does not explicitly say 'use query_memory when you only need structure', so the when-not is implied rather than 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the result is structure-only with no content and shares query_memory's shape, which is useful context, but the 'reserved/when γ lands' framing leaves it unclear whether it is operational now.

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 little waste, and the structure-only constraint is front-loaded. But the β/γ symbolic notation and the 'reserved for...' clause consume space without clarifying behavior for a reader who lacks the internal shorthand.

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 partially compensates by naming the return shape and equating it to query_memory. Beyond that it leaves the nested 'plan' object's relationship to the output and the tool's present-day readiness ambiguous, which is a real gap for a query 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 description coverage is 100% for the single 'plan' object, so the schema already carries the parameter detail. The description only alludes to 'a structured query' and adds no syntax or value guidance beyond what the schema documents; 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?

The verb 'render' and resource 'structured query' are present, and it distinguishes itself by stating the output is a 'STRUCTURE-ONLY result set' with 'identical shape to query_memory.' However, the cryptic 'β = structure' / 'γ' notation and the framing as 'reserved for richer rendering' muddy whether this tool is even currently usable.

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 implies a future condition ('reserved for richer rendering when content access (γ) lands') but never states when an agent should pick this over query_memory or query_memory_content. No explicit when-to-use or when-not-to-use guidance is provided against eight siblings.

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

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

Beyond the annotations' safety profile (readOnly, idempotent, non-destructive), it discloses that the route relays the upstream API and returns ENYAL's answer unchanged, that `degraded:true` is inconclusive rather than an absence, and that the caller still needs an eyl_ bearer token even though the upstream route is keyless. These are exactly the behavioral traits annotations cannot convey.

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?

Front-loaded with the purpose, then the return shape, then the degraded caveat, then auth and validation. Dense and every sentence carries information, though the single run-on paragraph is heavier than it needs to 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?

No output schema exists, so the description carries the return contract itself (found, anchor_status with bsv_tx_id, chain_status, degraded) and explains the auth and invalid-input behavior. An agent has everything needed to call it correctly.

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 already 100% (the identifier param documents UUID/hex, 8-64 chars), so the baseline is 3. The description adds validation semantics the schema does not state: a non-UUID/non-hex id is refused with `invalid_id` and nothing is transmitted.

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 ('look up one identifier in ENYAL's PUBLIC verification index') and pins the scope with 'no decryption'. This clearly separates it from the sibling retrieval tools (get_entity, query_memory, get_node_content), which fetch rather than verify.

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 establishes clear context: this is a public verification lookup, not a content/decryption call, and it covers the failure path ('invalid_id ... nothing is sent'). It does not explicitly name an alternative sibling or state a when-not condition, so it stops short of a 5.

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