Erinys Timeline

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 implies a read-only temporal query, but does not state whether superseded facts are included, how null as_of behaves (current time?), what permissions are required, or how results are ordered. The as-of framing is genuinely useful context, but major behavioral gaps remain for a tool with zero annotation coverage.

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 and free of waste. But for a tool with no annotations and 0% schema coverage, this level of brevity is under-specification rather than effective 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?

An output schema exists, so return values need not be explained. Still, with no annotations, no parameter documentation, and only a vague temporal qualifier, an agent lacks enough information to invoke this tool confidently or distinguish it from its many retrieval siblings.

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. It only gestures at 'as_of' via 'specific point in time' and says nothing about the expected format of that timestamp or what the required 'query' parameter accepts (natural language, fact ID, filter expression?). Both parameters are left semantically undefined.

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 ('Query') and resource ('facts') with a temporal qualifier ('valid at a specific point in time'), so the core purpose is inferable. However, it never explains what a 'fact' is in the Erinys domain or how this differs from siblings like erinys_recall, erinys_search, or erinys_get, leaving ambiguity about which tool an agent should pick.

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

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

There is no guidance on when to use this tool versus the many retrieval siblings (erinys_recall, erinys_context, erinys_search, erinys_get). No prerequisites, no exclusions, and no indication of when a point-in-time query is preferable to a current-state query.

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