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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile. The description adds only that attributes are included in the returned metadata, with no permission, rate-limit, or return-shape detail beyond that.

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. Every clause contributes directly to 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?

For a simple one-parameter getter with rich annotations and no output schema, the description gives enough context to call the tool. It omits parameter documentation and does not detail the returned metadata structure, keeping it from being fully complete.

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 sole required parameter, model_id, is not explained in the description. The phrase 'a single model's metadata' implies an identifier is expected but provides no format or syntax guidance.

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 ('Get') and resource ('model's metadata') with singular scope ('a single model'), which distinguishes it from plural list siblings such as aris_list_models. It does not explicitly differentiate from attribute-listing siblings like aris_list_model_attributes, so it falls 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, no prerequisites, and no named alternatives. The agent must infer from the getter name and 'single model' phrasing that this is used to retrieve one model's metadata.

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 well: it discloses content-addressed storage, the base64 input contract, the KG linkage to :ProcessModel, and importantly the 'best-effort no-op when no engine is reachable' silent-failure mode. It omits auth/permission requirements and the returned value, so it is not fully complete.

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 sentences, purpose front-loaded, and each sentence adds distinct information (storage semantics, input contract, failure mode). Dense internal jargon like ':Blob + :ModelExport node' slightly hurts readability 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?

No output schema and no annotations, so the description should ideally state what the call returns (a blob/asset id) and any auth prerequisites. It covers storage and failure behavior well but leaves the return value and permission model unstated, which is a meaningful gap for an ingest operation.

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 params_json description already enumerates every field (model_id, data_b64, mime_type, model_name, export_format). The prose adds context that the bytes are base64 and out-of-band, but no syntax or field meaning beyond the schema, so the 3 baseline 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+resource ('Store a raw ARIS model export ... as a content-addressed KG blob') and names the concrete node types it creates (:Blob + :ModelExport linked to :ProcessModel). This clearly separates it from read/list siblings like aris_get_model and aris_list_models, though it does not explicitly contrast with the singular-plural sibling aris_ingest_models.

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 notes bytes are 'rendered/exported out-of-band by the caller', which hints at the precondition, but never says when to choose this tool over aris_ingest_models or the attribute-setting siblings. There are no exclusions or alternative-routing guidance.

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. It does disclose a genuinely useful behavioral trait — best-effort semantics and the exact failure payload {"ingested": None} when no engine is reachable. It omits other important traits for a graph-writing tool: whether ingestion is idempotent, whether it overwrites/deletes existing nodes, and any permission or rate-limit 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 core purpose and the failure behavior are front-loaded in tight sentences. The trailing 'CONCEPT:AU-KG.ingest.enterprise-source-extractor' tag is opaque jargon that costs a line without helping an agent decide or invoke.

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 and no output schema, the description covers the purpose, the underlying clients, and the failure mode, which is decent. It still leaves the agent without any idempotency, overwrite, or permission context, so it is only marginally complete for the risk profile.

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 parameter's schema text already explains both the empty/default (whole inventory) and model_id (single model with EPC objects and flowsTo edges) modes in detail. The description adds no syntax or format meaning beyond that, 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?

States a specific verb (ingest) plus the resource (ARIS models) and the destination (epistemic-graph as typed nodes), which is far more informative than the tautological title. It does not, however, explicitly distinguish itself from the sibling aris_ingest_model_export, which an agent could easily confuse it with.

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/when-not guidance and no routing to alternatives. The only usage signal is buried in the params_json schema description (empty → whole inventory, model_id → one model), and even that is parameter behavior rather than tool selection guidance.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the non-obvious context that this is a read-back for writeback idempotency, but says nothing about return shape or behavior when the model_id is unknown.

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 short sentence, front-loaded with the action and resource, and the parenthetical is compact. It earns its place, though the parenthetical could have been spent on more actionable detail.

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?

There is no output schema and no parameter documentation, so the description bears more burden than it carries. For a simple read-only list tool with full annotations this is minimally adequate, but it does not say what attributes are returned or how errors are surfaced.

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 there is one parameter (model_id) with no description. The phrase 'a model's attributes' implies the parameter identifies the target model, which is marginal added meaning but gives no format, source, or lookup guidance for the 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?

States a specific verb + resource (get a model's attributes) and adds a parenthetical purpose (writeback idempotency read-back). It is distinguishable from the write counterpart aris_set_model_attributes, but it does not explicitly contrast with read siblings such as aris_get_model, so it stops short of full 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 parenthetical 'used for writeback idempotency read-back' implies the scenario in which this is the right tool, which is more than nothing. However, it names no alternative and gives no explicit when/when-not conditions versus aris_get_model or aris_list_model_objects.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds domain value by specifying the connections are 'directed control-flow' rather than generic links, but says nothing about result shape, size, or ordering.

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 front-loaded sentence with no filler. It is efficient, though the same brevity contributes to the gaps in usage and parameter detail.

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 read-only list tool with annotations covering safety, the description is close to sufficient, but with no output schema and no parameter documentation it leaves the agent without any hint of what comes back or how the single required argument is used.

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?

One parameter (model_id) with 0% schema description coverage, so the schema does not compensate. The phrase 'a model's objects' implies the parameter scopes to a single model, but the description never mentions model_id, its format, or whether it is required.

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 ('List') and resource ('directed control-flow connections between a model's objects'). This is naturally distinguishable from aris_list_model_objects and aris_list_model_attributes, though it never names those siblings to reinforce 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?

No guidance on when to use this versus the other aris_list_* tools or aris_get_model, and no prerequisites (e.g., model must exist or be ingested first). The agent must infer the right tool from the 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral value is clarifying the scope of returned entities (EPC functions/events/rule operators); it says nothing about pagination, volume, or ordering.

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 front-loaded sentence with zero filler; the scope qualifier is placed directly on the resource it modifies.

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 read-only list tool whose annotations carry the safety profile and with no output schema to explain, the description is adequate on purpose but silent on the one parameter it requires and on return shape/pagination. Minimum viable rather than complete.

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 there is one required parameter, model_id. The description never explains what a model_id is, its format, or how to obtain one (e.g., from aris_list_models), so it does not 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?

Specific verb (List) plus resource (EPC objects of a model), and it enumerates what counts as an object (functions/events/rule operators). That enumeration implicitly separates it from siblings like aris_list_model_connections and aris_list_model_attributes, though no sibling is named.

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 when-to-use guidance, no prerequisites, and no mention of the alternatives (list_model_attributes, list_model_connections, get_model) that an agent would need to choose between. Usage is only inferable from the name and the required model_id.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description's remaining contribution is that the listing spans both process and architecture models within the tenant/database scope, which is genuinely useful context but thin. It says nothing about result size, pagination, or filtering 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?

A single tight sentence with the scope front-loaded and zero filler. It is appropriately short for a simple list tool, though the parenthetical at the end is the only place any real information is added.

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-in-practice list tool with no output schema, the description is minimally adequate. However, it leaves the opaque params object unexplained and gives no indication of result structure or volume, so an agent still lacks information needed to call it optimally.

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 single optional 'params' parameter is an opaque object (additionalProperties: true) with 0% schema description coverage, and the description never mentions it. With schema coverage this low, the description is expected to compensate, but it gives no hint about what the params object accepts or how it filters the listing.

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 (List) and resource (models) and scopes it to the tenant/database, plus clarifies the model types covered (process + architecture). This distinguishes it from the ingest/set siblings, though it does not explicitly contrast with aris_get_model or the other aris_list_model_* siblings.

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 when-to-use guidance or alternatives are provided. The description never says when to enumerate models versus fetching one with aris_get_model, nor when to reach for aris_list_model_objects or aris_list_model_attributes instead. Usage is only weakly implied by the verb 'List'.

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=false, idempotentHint=true, and destructiveHint=false, so the description need not restate the safety profile. The example ('kg_intelligence blob') adds a small amount of domain context about the attribute payload, but the description does not clarify merge-vs-replace semantics, permissions, or other behavioral details beyond what annotations provide.

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 wasted words. It is efficient, though its extreme brevity leaves important details unstated, which is a completeness issue rather than a conciseness one.

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 that writes an arbitrary nested attributes object with zero schema descriptions and no output schema, the description is inadequate. It provides only a lone example and omits parameter details, write behavior, and any operational guidance, though annotations cover the safety profile.

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 carry the burden of explaining parameters, yet it gives only a vague example attribute name. It does not describe the model_id format, the shape of the attributes object, or which fields are required, leaving both required parameters effectively undocumented.

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 (Write/update) and resource (attributes on a model), making the tool's purpose immediately clear. It does not explicitly differentiate from siblings like aris_set_object_attributes, but the model-vs-object scope is inferable from the name and description.

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 tool versus alternatives, no prerequisites, and no exclusions. The description only says what it does, leaving the agent to infer when it is appropriate.

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 annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so 'write/update' is largely redundant with structured data. The description contributes no additional behavior — no merge-vs-replace semantics, no auth/permission requirements, no note on what happens to unlisted attributes.

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 or repetition. The brevity is earned structurally, though it is under-specification rather than true conciseness.

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 mutating tool with a nested open-ended object parameter, no output schema, no schema descriptions and only one line of prose, an agent lacks the information needed to call it confidently. The mutation semantics and attribute format are the main missing pieces.

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 two parameters are undocumented: object_id's expected identifier form and the attributes object's key/value shape and naming convention are unexplained. Critically, the description never says whether attributes are merged into existing ones or replace them, which is the single most consequential semantic for a 'set' tool with a free-form nested object.

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 pair (write/update) and resource (attributes on a single object), and the scope word 'single object' separates it from the sibling aris_list_model_objects and from the model-level aris_set_model_attributes. It's clear enough to route on, 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?

There is no when-to-use guidance, no prerequisites (e.g., must the object already exist, does it need a lock/checkout), and no mention of how this differs from aris_set_model_attributes or the list_* readers. The agent is left to infer everything from the name.

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