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

No annotations are provided, so the description carries the full burden. It does add one genuine behavioral constraint — reads are scoped to an 'allow-listed graph' — but says nothing about behavior for unknown/unauthorized UUIDs or error semantics. The output schema already covers the return shape.

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 resource and the keying mechanism front-loaded. No filler, nothing redundant with the 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?

For a one-parameter read lookup with an output schema defined, the description supplies what the agent needs: the resource, the identifier, and the access scope ('allow-listed graph'). Remaining details live in the schema rather than the prose.

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 the single uuid parameter, but the name plus the description's 'by UUID' phrasing makes clear it is the edge identifier. No format requirements or provenance guidance (where the UUID comes from) are given, which is the remaining 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?

The description states a specific verb and resource: retrieve a single fact edge, keyed by UUID. 'Fact edge' is precise terminology that separates it from the episode- and node-oriented siblings, though it does not name an alternative tool 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?

Usage is only implied: 'by UUID' signals this is a direct lookup that requires an identifier obtained elsewhere (e.g., from search_memory_facts or search_nodes). There is no explicit when-to-use statement or named alternative.

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

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

With no annotations, the description carries full disclosure burden. It does communicate the directionality of the relationship (episodes -> entities/facts), which is a genuine behavioral trait, but it says nothing about permissions, result limits, deduplication, or whether it is purely read-only.

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 core relationship front-loaded and no filler. It earns its length, though the extreme brevity is also the source of the coverage gaps noted elsewhere.

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?

An output schema exists, so return values need not be described. However, for a tool with an unspecified group_id and a required uuid array, the description leaves key invocation details (group scoping, uuid semantics) unaddressed, making it only minimally 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%, so the description must compensate for the undocumented parameters and it does not. It hints at episodes but never explains episode_uuids format/plurality nor the meaning or scoping effect of the optional group_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 (trace) plus the resource and relationship (entities and facts produced by source episodes), giving an agent a clear picture of the operation. It does not explicitly contrast against siblings like get_episodes or search_memory_facts, so sibling differentiation is left to inference.

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 phrasing 'produced by source episodes' implies when this is useful (finding the entities/facts derived from known episodes), so usage is implied rather than stated. There is no explicit when-not guidance nor any named alternative to route to when the agent lacks episode IDs.

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

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

No annotations are provided, so the description carries the full burden. It discloses only that results are 'most recent' and drawn from 'configured groups'; it says nothing about the read-only nature, the default cap of 10 episodes, ordering guarantees, or pagination behavior for a tool that could return many records.

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?

It is a single efficient sentence with the core resource and scope front-loaded and no filler. The brevity is appropriate, though it leaves substantive gaps rather than being padded.

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?

An output schema exists, so return values need not be explained, but for a 2-parameter tool with no annotations and zero schema description coverage the description is too thin. It omits parameter behavior, selection guidance relative to siblings, and any result-size or ordering context.

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

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

Schema description coverage is 0% for both parameters, and the description does not compensate. 'Configured groups' only loosely gestures at group_ids and says nothing about max_episodes or its default of 10, so an agent gets no added meaning beyond the raw schema.

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

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

The description names a specific verb and resource ('Return the most recent source episodes') and scopes it to 'configured groups,' which is clearer than a bare name restatement. However, it does not distinguish itself from the sibling get_episode_entities, leaving the agent to infer the difference between retrieving episodes and retrieving an episode's entities.

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 statement of when to use this tool versus search_nodes, search_memory_facts, or get_episode_entities. The phrase 'from configured groups' implies a default scope but does not tell the agent when to supply group_ids or when to prefer a sibling.

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

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

With no annotations, the description must carry the behavioral load, and it does state the scope (server plus its configured database connection), implying a read-only diagnostic with no side effects. It stops short of describing what a healthy vs. unhealthy result implies or any auth/rate-limit considerations, though the output schema likely covers the result shape.

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; every word earns its place for a zero-argument diagnostic 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?

An output schema exists, so return values need not be explained, and the description adequately conveys the check's target. It could optionally note what the check is for (e.g., verifying connectivity before queries), but nothing required for correct invocation 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 the baseline of 4 applies. The description correctly adds no parameter detail because none is needed.

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

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

States a specific verb ("Check") and resource ("the server and its configured database connection"), which clearly separates it from the data-retrieval siblings like search_nodes and get_episodes. It does not explicitly name those siblings as alternatives, but the health-check intent 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?

Usage is only implied: an agent infers this is a connectivity/health probe to run before or after other calls. There is no explicit statement of when to call it versus the siblings, nor any preconditions or failure-handling 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?

No annotations are supplied, so the description carries the full burden. 'Search' implies a read, but the description discloses nothing about return shape, result limits, ordering, or pagination behavior. For a 9-parameter tool this is a substantial behavioral gap.

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 efficient sentence with the core purpose front-loaded and no filler. It is terse to the point of under-specification, but structurally clean.

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?

An output schema exists so return values needn't be explained, but with no annotations, 0% schema coverage, and nine parameters, the definition is too thin. It omits which filters are required, how time bounds behave (valid_at vs invalid_at), and how results are limited, leaving the agent under-equipped 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 description coverage is 0%, so the description must compensate for all nine parameters. It names filter categories (type, time, group, center) that map loosely to edge_types, valid_at/invalid_at, group_ids, and center_node_uuid, but leaves query and max_facts unaddressed and gives no format or semantics (e.g. date format, uuid meaning) beyond the bare parameter names.

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 (search) and resource (temporal facts) and enumerates the filter dimensions (type, time, group, center). It is clear what the tool does, but it never distinguishes itself from the sibling search_nodes, so an agent must infer the boundary between facts and nodes.

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 or when-not-to-use guidance and no reference to any alternative (e.g. search_nodes for entities, get_episodes for episodes). The agent is left to guess which of the six sibling search/get tools applies.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It states a restriction ('Requests are restricted to configured groups'), which is useful, but doesn't disclose return behavior, pagination, or whether the search is semantic or keyword-based. For a search tool with 5 parameters and no annotations, this is insufficient.

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

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

The description is two short sentences and front-loads the core purpose. There is no wasted text, but it is under-specified for a tool with five parameters and no annotations. It earns credit for efficiency but not for completeness.

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?

An output schema exists, so return values need not be explained. However, the description is missing parameter explanations entirely (0% schema coverage) and provides no usage context. For a search tool with five parameters and no annotations, it is significantly incomplete.

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

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

Schema description coverage is 0%, meaning none of the 5 parameters are described in the schema. The description adds no parameter information at all. With zero coverage, the description should compensate but completely fails to do so.

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 says 'Search graph entities', which is a clear verb + resource. However, it doesn't distinguish this tool from sibling tools like search_memory_facts or get_entity_edge. Without sibling differentiation, it's merely adequate.

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. The only contextual clue is 'Requests are restricted to configured groups', which is a constraint, not usage guidance. The agent must infer when this is appropriate.

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