BankWeave

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

Annotations already cover read-only, idempotent, and non-destructive status, so the description is free to add the traits that matter: the expansion is 'bounded' to 1-2 hops, the depth is controllable, and results span multiple banks. It also discloses the underlying read path (GRAPH.RO_QUERY), which reinforces the safety profile. It doesn't discuss result volume 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?

The returned fields are front-loaded in one dense sentence, with the caveat about single-bank visibility immediately after. The trailing 'FalkorDB features: GRAPH.RO_QUERY, bounded undirected expansion' is implementation detail that adds little for an agent and is the one expendable fragment.

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 does the heavy lifting by enumerating the returned components (scores, shared identity, cases/alerts, counterparties at other banks, bounded neighbourhood). Combined with the annotations covering safety, an agent has enough to call it correctly, though the depth parameter's valid range remains 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?

Schema coverage is 0%, so the description carries the burden. It hints at the meaning of depth via 'bounded 1-2 hop neighbourhood' and 'depth' defaults to 2, but neither parameter is explicitly explained and the valid depth range is never stated.

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 resource (an account's cross-bank neighbourhood in the consortium graph) and enumerates exactly what it returns, which lets an agent distinguish it from siblings like similar_accounts or connected_components. It stops short of an explicit verb, but the scope is unmistakable.

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 and no alternatives named. The line 'A bank alone only sees its own side of these links' is domain framing, not a condition for choosing this tool over trace_money_path, similar_accounts, or run_readonly_cypher.

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 behavior, so the safety profile is covered. The description adds genuine value beyond that: results are ordered largest-first, the return payload includes per-component size, bank counts and member samples, and it names the underlying FalkorDB primitive (algo.wcc).

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 dense sentences, front-loaded with the computation and followed by the output and parameter hints; no filler. The telegraphic, jargon-heavy phrasing ('triage clears instantly', 'algo.wcc') costs a little readability but not correctness.

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 usefully summarizes the return payload and ordering, which is exactly what the agent needs. The only real gap is the undocumented 'limit' parameter for a tool that is otherwise well covered.

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 carries the burden. It does document the accepted 'graph' values ('consortium', 'bank_<id>', 'case_<id>'), which is real added meaning, but the 'limit' parameter is never explained beyond the implicit largest-first ordering.

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 algorithm and resource ('weakly connected components of the transfer graph') and enumerates the output shape (size, bank count, sample members, tiny-island count), so an agent knows exactly what this computes. It does not explicitly distinguish itself from graph-analysis siblings like find_rings or top_hubs, though the algorithm name implicitly separates it.

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: the mention of tiny 'islands' that 'triage clears instantly' hints this is a triage/orientation tool, but there is no explicit when-to-use statement or named alternative such as find_rings or account_network. An agent must infer the 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered without the description. The description adds the underlying implementation (FalkorDB INFO memory, GRAPH.LIST, RO_QUERY aggregations), which implies a cheap-ish aggregate read but says nothing about cost, 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 compact sentences, front-loaded with the returned content and followed by the orienting instruction. The trailing implementation-detail sentence (INFO memory, GRAPH.LIST, RO_QUERY) is the least valuable part for an agent, but it is brief and does not bloat the definition.

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 carries the burden of describing the return payload, and it does so by enumerating every section returned. It is nearly complete for calling purposes; only the shape/volume of the response 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 tool takes zero parameters (100% schema coverage), so the baseline is 4. There is no parameter syntax the description could clarify, and it correctly avoids inventing any input options.

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 concrete resource and scope — system health/size — and enumerates exactly what is covered (FalkorDB memory/version, graphs, consortium counts, alert queue by status). Sibling differentiation is implicit rather than stated: an agent can infer this is the composite overview versus single-purpose siblings like list_graphs or list_alerts, but no alternative 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?

"Call this first to orient yourself" gives a clear positive usage context: this is the entry-point call before drilling into specifics. It does not state when not to use it or name the siblings it supersedes, so it stops short of explicit routing.

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, yet the description reinforces with 'the score is recomputed in memory, nothing is written' and discloses what the response contains (origin groups, multiplicity, weights, unexplored origin kinds, evidence Cypher). That is real behavioral context beyond the annotations, though permission/authorization needs are unstated.

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?

Purpose is front-loaded in the first clause, followed by output shape and safety. It is dense but each sentence carries information; the trailing FalkorDB implementation notes (GRAPH.RO_QUERY, variable-length DERIVED_FROM traversal) are the weakest, least selection-relevant part.

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 comprehensively enumerates the return payload, and the read-only nature is covered. The one genuine hole is the total absence of parameter meaning, which matters for a 2-required-param 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 0% for both required parameters, and the description never mentions case_id or claim_id – not their format, scoping, or whether they must already exist. With 0% coverage the description was obliged to compensate and 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?

States a specific verb+resource and the exact mechanism: 'Why a claim has the confidence it has (GraphEcho echo-proof scoring)'. It also spells out the core concept (echo-proof vs naive path counting) that separates it from generic siblings like run_readonly_cypher or trace_money_path.

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?

Implied usage is clear – call it to understand a claim's confidence – and 'Pure read' signals a safe diagnostic role. However, it never states when to reach for this instead of run_readonly_cypher or trace_money_path, and there are no exclusions or prerequisites described.

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/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the algorithm used (algo.labelPropagation) and the ranking rule ('cross-bank rings come first, since no single bank can see them whole'). It does not disclose the return shape (does a ring include its member accounts?) or how limit interacts with ring ordering, which matters since there is no output schema.

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 core definition, then mechanism, then ranking, then the account_id filter — a sensible order. The trailing 'FalkorDB features: algo.labelPropagation' partially restates the mechanism already named in sentence one, a small redundancy, but the whole is tight and free of filler.

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 5-parameter, zero-coverage tool with no output schema and no sibling differentiation, the description covers purpose and filtering well but leaves parameter meaning and result structure underspecified. An agent can invoke it correctly with defaults, but cannot reason about what min_size/max_size do or what a returned ring looks like.

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% across 5 parameters, so the description must compensate — and it only explains account_id. limit, max_size, min_size, and graph are left entirely to inference from their names, with no statement of what max_size/min_size bound (ring membership count?) or whether limit caps rings or accounts.

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 ('find rings' = communities of accounts that trade mostly among themselves) and pins down the mechanism (label propagation on the transfer graph). This distinguishes it clearly from siblings like connected_components, account_network, and similar_accounts, which an agent could otherwise confuse with ring detection.

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 branch — 'Pass account_id to return only the ring that contains that account' — which is genuinely helpful. However, it never says when to prefer this over connected_components or account_network, nor whether these are candidate leads that should be confirmed via explain_claim or triage_alert. Usage is implied rather than contrasted with alternatives.

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/non-destructive, so safety is covered; the description adds genuinely new behavioral context — one graph per case, GRAPH.RO_QUERY execution, and the state vocabularies (active/needs_verification/superseded) and confidence variants that shape results. It stops short of noting limits like pagination or truncation 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?

The single sentence is front-loaded with the core purpose and then packs the return contents densely; every listed element is informative rather than filler. Slightly long, but the enumeration is warranted given there is no output schema.

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, enumerating header, claims, evidence, actions and SAR status is exactly what an agent needs to interpret results, and the graph-engine note explains the data model. The only gap is the unexplained max_evidence cap, which affects how complete results will be.

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 carries the burden. It compensates well for case_id by giving the literal format ('C-44c08392'), but says nothing about max_evidence (default 40) or what it limits, leaving one of two parameters 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?

States a specific verb and resource ('Everything about one case from its own case graph') and enumerates the exact scope of the payload, which cleanly separates it from the sibling list_cases (one case vs many). An agent can identify the tool's job without opening the 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 description implies use when you already have a case_id but never states when to prefer this over list_cases, explain_claim, or run_readonly_cypher, nor any preconditions for obtaining the id. No when-not or alternative routing is provided.

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, and openWorldHint=false, so the safety profile is clear. The description adds that it returns schema elements and index kinds, but does not disclose return format, size, or behavior for a missing graph. With annotations covering the safety profile, a 3 reflects useful added context but not rich behavioral 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 compact and front-loaded, stating the resource and outputs first, then graph examples, then FalkorDB functions. Every sentence earns its place, though the trailing FalkorDB feature list is somewhat technical and could be trimmed without loss.

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-parameter read-only introspection tool with no output schema, the description is nearly complete: it identifies the resource, the schema elements returned, index kinds, and example graph values. The main gap is lack of return structure or behavior for invalid graph names, but the annotations and single parameter keep the burden low.

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 schema does not document the 'graph' parameter beyond its name and default. The description partially compensates by listing example graph names ('consortium', 'bank_<id>', 'case_<id>', 'typology_kb'), which is helpful, but the mapping of the 'bank_<id>'/'case_<id>' patterns is vague and there is no mention of an enum or valid-id format. Baseline 3 is appropriate given partial compensation.

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: it returns the schema of one graph, enumerating node labels, relationship types, property keys, and indexes with their kinds. This clearly distinguishes it from sibling tools like run_readonly_cypher or list_graphs, which operate on data or enumerate graphs rather than describe a single graph's 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?

Implicitly used before writing Cypher queries to learn the schema, but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternatives like run_readonly_cypher or explain how it complements them, leaving usage context 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 readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: counts grouped by status, the meaning of each status value, and the fields carried on each alert. The trailing FalkorDB/GRAPH.RO_QUERY note is implementation trivia rather than 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-loads the purpose and the status semantics, then the returned fields and the hand-off to triage_alert. The closing 'FalkorDB features' sentence adds little for an agent and slightly dilutes an otherwise tight definition.

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, describing the per-alert fields (rule, reason, account, bank, case id, clearing reason) is exactly what an agent needs to use the results. For a two-parameter read tool, this is close to complete; only pagination behavior is unaddressed.

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 the description must carry the load, and it does for status by enumerating 'open', 'case', 'cleared' and the omit-for-all default. Only limit goes unexplained, but its name and default of 20 make it largely self-evident.

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 and scope: 'the alert queue with counts by status', plus the per-alert fields returned. It differentiates from triage_alert by pointing to it for alert-id lookups, though it never contrasts with the sibling list_cases.

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?

Gives clear conditional usage for the status filter ('omit for all') and routes the agent to triage_alert once an alert id is in hand. It does not state when not to use this tool or when list_cases would be the better entry point.

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 and destructiveHint=false, so safety is covered. The description usefully adds the newest-first ordering and the contents of each row, but says nothing about the limit parameter's default or truncation behavior, which is the one behavioral risk for a list 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?

Front-loaded with the resource and returned fields, then the sibling routing hint — all in two sentences. The trailing 'FalkorDB features: GRAPH.RO_QUERY over the consortium graph' is an implementation detail that adds little selection value for an 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?

With no output schema, the description usefully enumerates the returned fields, which is the main completeness requirement here. The only real gap is the undocumented limit parameter (default, truncation), and annotations already 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?

The single parameter (limit, default 30) has 0% schema description coverage and is never mentioned in the description, so nothing compensates for the gap. 'Newest first' hints at ordering but not at how many rows come back or what limit does.

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 ('List investigation cases') and enumerates exactly what each row contains (status, title, seed account, alert/account counts, banks, graph-loaded flag). It also names the sibling get_case as the detail-lookup counterpart, so the agent can separate the two without opening schemas.

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?

Gives clear context: this is the enumeration entry point, and 'Use a case id with get_case' explicitly routes detail retrieval to the sibling. It does not say when *not* to use it or how it relates to other listing tools like list_graphs or list_alerts, so it falls short of full when/when-not 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value by disclosing the shape of the result: graphs come grouped by kind with a defined taxonomy, which the 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?

Two sentences, zero filler: the enumeration of graph kinds is front-loaded and the follow-up pointer is placed after it. 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?

With no output schema, the description carries the burden of explaining return values, and it does so by describing the grouping taxonomy. Combined with annotations covering safety and the absence of parameters, nothing material is missing.

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 takes zero parameters, so there is nothing for the description to explain and the baseline is 4. The only identifier mentioned, graph_schema(graph), belongs to a sibling tool rather than this one.

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 (FalkorDB graphs) and immediately enumerates the four categories those graphs fall into (consortium, per-bank, per-case, typology KB). This is enough to distinguish it from siblings like graph_schema or engine_overview without opening any 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?

Explicitly routes the agent to graph_schema(graph) for labels, relationship types and indexes, which is a real follow-up need after enumeration. However it never states when this tool should be preferred over other discovery tools or what a caller should do with the kind grouping, so usage context is clear but not fully bounded.

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 confirm read-only, idempotent, non-destructive, closed-world behavior. The description adds rich guard details: engine rejects writes, single statement, banned clauses, CALL restrictions, automatic LIMIT, 200-row cap, and 10s timeout.

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 'Last resort' and packed into one dense but necessary paragraph; every clause covers a distinct guard or parameter. No filler.

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 complex, high-risk query tool with no output schema, the description supplies enough behavioral context: safety guards, row/time limits, graph options, and a pointer to graph_schema. An agent can 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 0%, so the description must compensate. It lists allowed graph values ('consortium', 'bank_<id>', 'case_<id>', 'typology_kb') and constrains the cypher string, but does not explicitly explain the limit parameter's default or its relationship to the automatic row cap.

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 (run) and resource (read-only Cypher on one graph), and 'last resort' frames its scope relative to sibling tools. An agent can distinguish it from graph_schema or trace_money_path without opening the 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?

'Last resort' gives a clear condition for use and implies when not to use it (only after other tools). However, it does not name specific alternative tools for the same querying goal, leaving that 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the search is fuzzy/token-OR-ed, spans all banks, and returns each match's owned accounts and banks. It does not state result limits or behavior on empty results.

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 capability and search semantics are front-loaded in the first two sentences, which are tight and information-dense. The trailing sentence 'FalkorDB features: full-text index, db.idx.fulltext.queryNodes' is internal implementation detail that does not help an agent select or invoke the tool, so it does not fully earn 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?

With no output schema, the description helpfully describes the return shape (matches plus their accounts and banks). Combined with annotations covering safety, an agent has enough to call it correctly, but the undocumented 'k' limit and the absence of any guidance on zero-result or large-result behavior leave a small 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 0%, so the description must carry parameter meaning and only partly does. It implies the Person/Company distinction that maps to the 'label' parameter (default 'Person'), but the 'k' limit parameter is never mentioned, leaving one of three parameters undocumented in both schema and description.

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 (fuzzy name search) and resource (customers/businesses) with explicit scope ('across all banks') and even the result payload ('the accounts and banks each one owns'). No sibling tool in the list performs entity lookup by name, so the tool is unambiguously distinguishable from graph-analytics siblings like find_rings or trace_money_path.

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 description notes tokens are OR-ed so 'partial names work', which tells the agent how to phrase input but not when to prefer this over alternatives. There is no when-not guidance, no mention of what to do when a name is ambiguous or yields no matches, and no named alternative 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's real contribution is the ranking semantics: distance is cosine over behavior_vec and lower means more alike. That directionality is genuinely useful and non-obvious, though return shape and result-size behavior are left unstated.

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 definition is front-loaded in one dense, useful sentence, followed by a use case. The closing implementation trivia ("HNSW vector index, db.idx.vector.queryNodes") adds little for a caller and is the only sentence that does not fully earn 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?

With no output schema, the description should pin down the return shape more than "with their banks"; k is undocumented and there is no mention of ordering guarantees or result limits. It is adequate to call the tool but leaves the agent guessing about output size and fields.

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 carries the full burden for two parameters. It says nothing about account_id or, more importantly, k (the result count, default 5) – an agent cannot tell from any source how many neighbors it will get back.

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 concrete operation: ranking accounts by cosine distance over Account.behavior_vec and returning them with their banks. It is specific about the mechanism and result, though it never explicitly contrasts itself with structural siblings like account_network or connected_components, which is what a 5 would require.

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?

"Useful to find mule accounts that act like a known one at other banks" gives a clear investigative context for when to reach for it. It stops short of naming alternatives or stating when-not to use it (e.g., for structural rather than behavioral similarity).

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 behavior, lowering the bar. The description adds useful context beyond them: the algorithm (PageRank), the edge type it runs over (TRANSFERS), the ordering (highest first), and that results carry bank ids. It does not cover scale limits 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?

Dense and front-loaded: the core behavior leads, then graph values, then an implementation note. The trailing 'FalkorDB features: algo.pageRank' is marginal metadata but brief enough not to bloat the definition.

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 only safety annotations, the description does convey the return shape (ranked accounts with bank ids). However it omits how top_k bounds results and what happens across the different graph scopes, leaving gaps for a 2-parameter analytical 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 coverage is 0%, so the description must compensate. It usefully enumerates valid graph values ('consortium', 'bank_<id>', 'case_<id>'), which the schema lacks, but leaves top_k unexplained beyond the implied 'highest first' ordering.

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 concrete resource and method: accounts ranked by PageRank over TRANSFERS, returned highest-first with bank ids. This clearly distinguishes it from siblings like connected_components, find_rings, and trace_money_path, 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 or comparison against alternatives; the closest thing is the graph value enumeration, which is parameter help, not usage routing. The agent must infer that this is the money-pooling/centrality tool from the phrase 'where money pools'.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower; the description still adds real behavior: directional scope changes with case_id, absence of a path means no claim, and the underlying algorithm (FalkorDB algo.SPpaths). It does not disclose how max_len/path_count defaults shape results or what a truncated search means.

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 what the tool produces, then the case_id branching, then the caveat. Sentences are dense and earn their place, with only the trailing 'FalkorDB features: algo.SPpaths' being an implementation detail of marginal value to an agent choosing a 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?

With no output schema, the description correctly describes the return shape (hop-by-hop paths with transaction ids, amounts, and banks) and the null result case. Combined with read-only annotations, an agent has enough to call it and interpret results; the remaining gap is the effect of max_len and path_count on truncation.

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% across 5 parameters, so the description must compensate. It does explain the semantics of case_id well (consortium search vs. case-graph bidirectional search), and src/dst are self-evident. But max_len and path_count — which directly bound the result — get no explanation of units, bounds, or effect, leaving the most result-shaping params undocumented in both places.

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 ('shortest money paths from one account to another') plus the exact payload of each hop (transaction ids, amounts, bank of every account). This is clearly separable from siblings like find_rings, account_network, and connected_components, which explore graph structure rather than tracing a directed path between two named accounts.

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 a genuine when-to-use rule tied to an argument: without case_id it scans the consortium along outgoing transfers, with case_id it searches that case's graph bidirectionally. 'No path = no claim' is a useful negative-result caveat. It stops short of naming an alternative sibling for the no-case, exploratory case (e.g. account_network), so it is clear context without explicit 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the split between recorded graph signals and a LIVE re-check, the fact that islands below the configured threshold clear instantly, and the underlying FalkorDB features (algo.wcc, GRAPH.RO_QUERY).

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 front-loaded with the purpose, then the returned fields, then the live re-check semantics, followed by the engine features. It is dense but each clause carries information; only the trailing FalkorDB feature list is arguably incidental implementation 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?

With no output schema, the description carries the burden of describing returns, and it does so thoroughly by enumerating the alert, triage decision, reason, recorded graph signals, and live re-check values. Only edge cases such as behavior for an unknown alert_id are left unaddressed.

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 schema supplies only the name and string type for alert_id and the description does not compensate with format or sourcing details. The single parameter is largely self-explanatory by name, which keeps this at an adequate rather than deficient level.

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 resource (an alert's triage decision) and frames the purpose as explaining why it was cleared or escalated into a case. It is distinguishable from list_alerts and get_case, though it is phrased around return contents rather than a clear action verb, so it falls just short of the top score.

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 when-to-use or when-to-avoid guidance, and no sibling alternatives are named. The scenario is only weakly implied by the phrasing 'why an alert was cleared or escalated', leaving the agent to infer when this is preferable to list_alerts or get_case.

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 behavior, so the safety profile is covered. The description adds genuinely new traits: it abstains when nothing matches well (a critical expectation for callers), returns citations, and relies on a full-text index over the typology_kb graph, which signals fuzzy rather than exact matching.

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 sentences, front-loaded with the purpose and examples; nothing is padded. The trailing 'FalkorDB features' sentence is the weakest, reading as implementation detail, though it does hint at matching behavior.

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-parameter retrieval tool with no output schema, the description covers the essentials: what is retrieved, that citations accompany results, and that abstention is possible. More detail on the shape of a returned typology (fields, citation format) would make it 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?

There is a single required parameter with 0% schema description coverage, so the description must compensate. It partially does by giving two example question strings that show the expected natural-language style, but it never states constraints such as language, length, or whether keywords alone are acceptable.

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 concrete resource (laundering typology guidance from BankWeave's typology knowledge graph) and illustrates it with two sample typology queries, so an agent immediately understands what comes back. It does not explicitly contrast itself with siblings such as trace_money_path or run_readonly_cypher, leaving the distinction to inference, but the 'guidance/methodology vs. case data' framing is 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?

Example phrasings ('fan-out then fan-in through mules', 'structuring below reporting threshold') imply the kind of question to bring here, which is useful implied usage. However, there is no explicit when-to-use/when-not-to-use statement and no named alternative for agents who actually want to trace a specific path or query the graph directly.

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