Captia Industrial Knowledge

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose a non-obvious behavior: 'Returns warnings for inconsistent inputs instead of failing' and guarantees formula parity with the published calculator. This is sufficient for a simple calculation 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 three concise sentences with no filler. It front-loads the core purpose, then provides formula consistency and error-handling behavior, with every sentence adding value.

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?

The description covers the calculation purpose, output metrics, formula consistency, and error behavior. Although there is no output schema, the description names the computed values, so an agent knows what to expect. The main omission is the exact return structure, but that is minor for a simple deterministic calculation.

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?

All six parameters already have meaningful descriptions in the schema, so schema coverage is 100%. The tool description adds no parameter-level detail beyond the schema, which matches the baseline expectation of 3.

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 ('Compute') and a clear resource ('Overall Equipment Effectiveness from shift data'), then lists the exact output components (availability, performance, quality, OEE). The sibling tools are all unrelated knowledge/profile/protocol tools, so there is no ambiguity about what this tool does.

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 clearly frames when to use the tool: when OEE must be calculated from shift data. It additionally notes consistency with the published calculator, which is useful context for users deciding between this and manual computation. There are no similar sibling tools, so explicit exclusions are unnecessary.

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 of behavioral disclosure. It makes one valuable disclosure — that throughput and transport specs are deliberately not exposed because they aren't structured data — which sets accurate expectations. However, it doesn't disclose other behaviors such as error handling for invalid slugs or the return format.

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 with zero waste. The first sentence front-loads the purpose and the exact comparison dimensions; the second adds a single high-value limitation. Every word earns 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?

Complete enough for a 2-parameter comparison tool. The comparison dimensions are enumerated, and the key known limitation (no throughput/transport specs) is disclosed. Without an output schema, a bit more detail on return format would help, but the comparison nature of the tool makes the output largely self-evident.

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

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

Schema description coverage is 100% and both parameters are already documented there with useful detail (slugs: 'Use list_protocols to get valid values'; locale: enum values with a Spanish default). The description adds no parameter-level semantics beyond what the schema provides, so baseline 3 is correct.

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 (compare), a specific resource (industrial protocols), and explicit comparison dimensions (family, summary, ingestion method, target keywords). The scope is unambiguous and clearly differentiated from siblings like list_protocols, which presumably lists rather than compares.

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 makes clear when to use it (when a side-by-side protocol comparison is needed) but doesn't explicitly name alternatives or state when not to use it. The schema's slugs description adds the list_protocols prerequisite, but the description itself could name the sibling more explicitly.

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 full burden of disclosing behavior. It is transparent about the kind of data returned: legal details, contact info, business units, and declared knowledge areas. It does not describe the response format or potential locale behavior, but for a profile-retrieval tool the content disclosure is strong.

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 sentences with no filler. It front-loads the core identity content and then states the practical use case. Every part earns its place, and it is easy to scan.

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 tool with one optional parameter and no output schema, the description gives enough context for an agent to select and invoke it correctly. It explains what data will be returned and when to use it. It could mention the response shape or the default locale, but that information is either implied or available in the schema.

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 input schema fully documents the only parameter (locale) with an enum and description, achieving 100% schema description coverage. The tool description does not add extra meaning about the locale parameter, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: providing the identity of Captia Technology, including legal entity, tax id, offices, contact, business units, and knowledge areas. It distinguishes itself from sibling tools like calculate_oee or search_knowledge by focusing specifically on company identity. The phrase 'Use it to answer who Captia is or what each unit does' reinforces the exact resource and intent.

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 explicitly says when to use the tool: to answer questions about who Captia is or what its business units do. It provides clear usage context, though it does not explicitly mention when not to use it or name alternative tools for related but different queries.

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 behavioral disclosure burden. It discloses the glossary scope, the two accepted input formats (slug or label), and the fallback behavior for no-match cases. It also mentions locale defaults indirectly through the schema, so the few missing pieces (exact definition of a 'close suggestion', no error-handling detail) are minor for a read-only lookup 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 succinct—two sentences with no filler. The purpose and scope are front-loaded, and the fallback behavior is a compact addition that earns its place. Slight redundancy with the schema's example and the 'slug or label' phrasing could be trimmed, but overall it's efficient.

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, no-output-schema read-only lookup, the description is mostly complete. It provides the glossary scope, input constraints, and the no-match fallback, which is enough for an agent to decide and call correctly. The remaining gap is the lack of error/return-shape details, but that's not required for a lookup tool like this.

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

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

Schema description coverage is 100%, and the description adds little beyond the schema's own parameter documentation. Why the description does repeat the 'slug or label' semantics, the locale default and term example are already provided in the schema, so no additional meaning is required or provided.

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 ('Definition of an industrial term from the Capita glossary'), names the glossary scope (90 entries: protocols, OT/IT concepts, industrial AI, energy), and clarifies acceptable inputs (slug or label). It clearly differentiates this from sibling tools like search_knowledge or compare_protocols by focusing on a single-term lookup.

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 when to use the tool (when you need a term definition), and it also mentions a key fallback behavior: if no confident match, it returns close suggestions. However, it doesn't explicitly state when not to use it or name alternatives like search_knowledge or list_protocols, so usage guidance is more implicit than explicit.

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 explains the read-style behavior: it lists ingested protocols with family and summary and exposes valid slugs. It is not as detailed as a full behavioral contract (e.g. ordering, response shape), but the resource and purpose are clear.

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 short, front-loaded sentences with no filler. The first states the tool's result and the second gives the actionable relationship to compare_protocols.

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 optional-param list tool without an output schema, the description gives enough content expectations (family, summary, slugs) and the context for why the tool matters. It could only be more complete with a concrete output example or field list.

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

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

Schema description coverage is 100% and the single locale parameter is fully documented there, so the description adds nothing about parameters. Baseline 3 applies because the schema already carries the meaning.

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 ('industrial protocols Captia Connect ingests from'), and adds what is returned (family, summary). It also names the sibling it feeds, distinguishing list_protocols from compare_protocols.

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 tells the agent to call this before compare_protocols to learn valid slugs, which is clear usage context. It does not discuss when not to use it or alternatives beyond compare_protocols.

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 does disclose that only 'published editorial resources' and 'glossary terms' are searched and that output is 'canonical URLs,' which is useful context. But it omits other behavioral details such as result ordering, whether snippets are included, or that the operation is read-only (though 'search' implies this).

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 sentence, front-loaded with the core action and scope, and ends with the essential return value. Every word 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 simple search tool with fully documented parameters, the description provides the essential information: what is searched and what is returned. The statement 'Returns canonical URLs' partially compensates for the lack of an output schema, though it doesn't describe the full result structure (e.g., titles, snippets, metadata).

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

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

Schema description coverage is 100%, and all three parameters (query, limit, locale) are already documented with descriptions, defaults, and constraints in the schema. The description adds no extra parameter meaning, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Full-text search') and names concrete resources: 'published editorial resources (guides, comparisons and technical articles on industrial data, OT/IT integration, industrial AI and energy) and glossary terms.' It also states the output type, 'Returns canonical URLs,' which clearly distinguishes it from sibling tools like get_glossary_term or list_protocols, though it doesn't explicitly name them.

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 usage: search the knowledge base when you need to find relevant content. However, it does not explicitly say when to prefer this over get_glossary_term for exact glossary lookups, nor does it provide guidance on query formulation or result handling.

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