Atinamos Evidence

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

With no annotations, the description carries the full burden. It usefully states that the tool returns eligibility only and not an Atinamos buy/no-buy instruction, and it enumerates supported policy keys. It does not explicitly disclose side-effect status, network dependencies, or failure behavior, leaving some ambiguity for an evaluation 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?

The description is compact and front-loads the main purpose before stating the important limitation and supported keys. The first two sentences are slightly redundant in expressing the eligibility result, but overall every sentence carries useful information.

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

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

Given no annotations, no output schema, and a nested policy object, the description is incomplete. It explains what the tool evaluates and which policy keys are supported, but it does not define the return shape, explain the endpoint parameter, or describe error conditions, leaving an agent uncertain about full invocation and result handling.

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 explains the policy object through the supported policy keys, but the required endpoint parameter is never described, and the nested structure of policy is left vague. This is a substantial gap for one of only two parameters.

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-resource pair, 'Evaluate evidence against procurement rules,' and clarifies the output is eligibility rather than a buy/no-buy instruction. This distinguishes the tool from the sibling evidence/search/history tools, though it does not name them 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?

The intended use is implied: call this when evidence needs to be checked against procurement rules supplied by the calling agent. However, there is no explicit guidance on when not to use it or how it compares to lookup_evidence, search_services, or service_history.

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 behavioral burden. It explains the returned object is the signed receipt itself and enumerates its verifiable contents: issuer key id, content hash, signature, timestamps, stages, assertions, and limitations. This provides useful behavioral context beyond the name, though it does not mention errors, auth, or side effects.

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 concise and well-structured. The first sentence states the action and resource immediately; the second provides valuable detail about the returned object and its verification use. Every sentence earns its place with no redundancy or 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 single-parameter retrieval tool with no output schema, the description is largely complete: it identifies the input, clarifies that the full signed receipt is returned, and lists the key fields an agent can expect. The main gap is the lack of guidance on when to prefer this over the sibling lookup tools, which is relevant given their overlapping names.

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 only parameter, receipt_id. The description does not explain how to obtain this ID, its format, or its relationship to the sibling lookup tools. The parameter name is self-explanatory at a basic level, but the description adds no meaningful semantic detail beyond the schema's 'Receipt Id' title.

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 clearly states a specific verb and resource: 'Retrieve one complete signed Atinamos Assurance Evidence Receipt.' It is obvious what the tool does. However, it does not explicitly differentiate itself from the semantically similar sibling 'lookup_assurance_evidence', so it falls short of a perfect 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?

The description implies the tool should be used when a signed receipt must be retrieved for independent verification, mentioning buyers can inspect and verify. But it provides no explicit when-to-use guidance, no exclusions, and no comparison to sibling tools like lookup_assurance_evidence or lookup_evidence.

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 provided, the description carries the behavioral disclosure burden and does so well: it discloses Buyer Read semantics, that the result is an unsigned convenience index, that it performs no invocation or payment, and that it returns no universal trust verdict. This is strong, though it does not cover potential auth, rate limits, or error 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 description is compact and front-loaded: the main purpose appears in the first sentence, with key behavioral caveats in the following sentences. Every sentence adds distinct information, and there is no filler or repetition of schema fields.

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?

Given the low parameter count and the absence of an output schema, the description provides a reasonable amount of context about what is returned and what is deliberately not returned. The main missing piece is the meaning of the optional method parameter, which prevents 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%, so the description must compensate for both parameters. It clarifies that the tool targets a 'service endpoint,' which maps to the required endpoint parameter, but the optional method parameter is entirely unexplained, leaving a meaningful gap in how the parameters should be used.

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 opens with a specific verb and resource: 'Look up signed Atinamos Assurance evidence for a service endpoint.' It also distinguishes itself from siblings by stating the result is an unsigned convenience index over signed Evidence Receipts and explicitly saying it returns no universal trust verdict, so an agent can tell it apart from tools like get_assurance_receipt or evaluate_policy.

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 useful context: it uses Buyer Read semantics, performs no service invocation or payment, and is not a trust verdict. However, it never explicitly says when to prefer this tool over sibling tools such as lookup_evidence or get_assurance_receipt, nor does it state when-not-to-use it relative to those 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?

With no annotations, the description must carry the behavioral burden. It reveals that results are timestamped observations and summaries, and explicitly disclaims a universal verdict. It does not mention not-found behavior or output format, but the read-only lookup nature is clear from 'look up' and 'returns'.

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 tight sentences: purpose first, then return value and boundary condition. Every sentence adds necessary information and there is no redundancy.

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 lookup with no output schema, the description covers what it returns, what it does not return, and the input predicate. It omits details like endpoint format and empty-result behavior, but the tool is simple enough that an agent can invoke it correctly from this definition.

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 supply endpoint semantics. It does, by stating the endpoint is the exact service endpoint used as the lookup key. No format/example is given, which is a minor gap, but the core meaning is communicated.

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 opening sentence names a specific verb ('look up'), a specific resource ('Atinamos verification evidence'), and a precise scope ('exact service endpoint'). It also actively distinguishes itself from policy evaluation by stating the tool does not return a universal trust or safety verdict.

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 'exact service endpoint' phrasing tells the agent this is the precise-match lookup, implicitly reserving search_services for discovery/fuzzy queries. The 'does not return a universal trust or safety verdict' sentence is a clear exclusion for verdict-type tasks, though it stops short of naming which sibling to use instead.

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 of behavioral disclosure. 'Search' implies a read-only operation, but the description does not explain matching behavior, result shape, pagination through limit, or corpus-specific 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 description is one short, front-loaded sentence with no filler. It is concise, though it achieves that by omitting important behavioral and parameter details.

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 two-parameter tool with no output schema and no annotations, this description is too sparse to let an agent confidently predict call behavior or interpret results. It conveys the operation's existence but not enough operational 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?

Input schema description coverage is 0%, and the description adds no meaning for either parameter. The agent is left to guess what fields 'query' targets and how 'limit' affects results.

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: it searches 'services represented in the published Atinamos evidence corpus.' This scope distinguishes it from siblings somewhat, though it does not explicitly contrast with lookup_evidence or service_history.

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

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

The phrase implies use this tool to find services within the evidence corpus, but it gives no explicit when-to-use or when-not-to-use context and names no alternatives. Usage must be inferred from the resource name rather than stated.

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

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

With no annotations provided, the description bears the full responsibility for disclosing behavioral traits. It only states that it 'returns' history, implying a read operation, but fails to mention any potential side effects, error conditions, pagination, authentication requirements, or limitations. The description adds minimal information beyond the basic action.

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, clear sentence with no redundant words. It front-loads the action and object, making it easy for an agent to quickly grasp the tool's purpose. There is no wasted information.

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

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

Given the absence of an output schema, annotations, and sibling differentiation, the description is too sparse. It does not explain what the returned history looks like (format, fields), nor does it clarify the meaning of 'published observation' or any constraints on the endpoint. An agent would likely need additional runtime errors or documentation to use this tool 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?

The schema has 0% description coverage for the single 'endpoint' parameter. The description provides some context by saying 'for one service route', which suggests the endpoint refers to a service route, but it does not clarify the expected format (e.g., URL, ID) or any constraints. This is insufficient compensation for the complete lack of schema-level documentation.

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 clearly states a specific action ('Return') and a specific resource ('Atinamos's published observation history for one service route'). It distinguishes itself from sibling tools by focusing on history, which is distinct from policy evaluation, evidence lookup, or service search. The purpose is unambiguous and immediately understandable.

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 provides no guidance on when to use this tool versus its siblings (evaluate_policy, lookup_evidence, search_services). It does not mention scenarios, prerequisites, or exclusions. An agent is left to infer that this tool is for retrieving history without any explicit contextual cues.

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