Agrus.ai — Enterprise AI Agency

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

With no annotations, the description carries the full burden. It discloses that case studies are NDA-protected, customer names are private, but codenames, technology, and outcomes are open. This is important behavioral context. It doesn't explicitly state that it's read-only or non-destructive, but that is implied by the retrieval nature.

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 sentences that are each meaningful: first describes what is returned and the privacy constraint, second explains filtering options, third gives usage guidance. No redundancy or irrelevant 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 output schema, the description adequately covers the purpose, filtering, and a key behavioral trait (privacy). It also provides a use case ('proof of prior work'). For a simple retrieval tool with 2 optional parameters, this is mostly complete. Could mention that it returns a list vs single object depending on args, but not essential.

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%, so baseline is 3. The description adds value by explaining the no-args option ('call with no args to list all') and the filtering logic ('or vertical'), though it doesn't restate that vertical is ignored if slug is provided (which is in schema). This addition is modest but sufficient to maintain the baseline.

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 'Returns one or more Agrus case studies' and explains how to filter by slug or vertical. It also says 'Use this for proof of prior work', distinguishing it from sibling tools like list_services or request_proposal.

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 'Use this for proof of prior work', giving a clear context for when to use this tool. It also explains the three call patterns: by slug, by vertical, or with no args. It could be improved by explicitly stating when not to use it, but the context is sufficient.

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 disclosing behavioral traits. It does not mention whether the tool is read-only, requires authentication, or has any side effects. The description only states what it lists, leaving the agent unaware of potential 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 two sentences, each earning its place. The first sentence lists the contents, the second gives a clear usage prompt. No wasted words and front-loaded with key 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 output schema, the description explains what the tool returns (six service pillars with details and four pricing tiers). This is sufficient for a simple list operation. The optional vertical filter is noted, and the overall context is complete for typical use.

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 has 100% coverage with a description for the only parameter (vertical). The tool description adds no extra meaning beyond what the schema provides. Baseline of 3 is appropriate as the schema already documents the parameter well.

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 it lists 'six service pillars with descriptions, deliverables, and price bands' plus 'four published pricing tiers'. It uses a specific verb and resource, and the sibling tools like get_case_study and list_verticals have distinct purposes. However, the output structure is implied but not fully detailed.

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 'Use this for the "what does Agrus do?" question', providing clear context for when to invoke this tool. It does not mention when not to use it or alternatives, but the context signal is strong enough to guide selection.

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 describes the output includes compliance pins, sample use cases, and sequencing rationale, which is appropriate for a read-only listing tool. It does not mention any side effects or authorization needs, but given the tool's nature, this is adequate.

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 consists of two concise sentences. The first sentence clearly lists what the tool does and the second provides usage guidance. Every word adds value, and the purpose is front-loaded. No fluff or 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?

Given the tool has no parameters, no output schema, and low complexity, the description is complete. It tells what the tool returns and why to use it. No additional information is necessary for an agent to select and invoke 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 input schema has no parameters (0 parameters), and schema description coverage is 100%. According to guidelines, when there are 0 parameters, the baseline score is 4. The description adds context about what the output contains, which is sufficient.

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 lists Agrus's seven year-one verticals with specific details like compliance pins and sample use cases. The verb 'Lists' and specific resource 'Agrus's seven year-one verticals' make the purpose unambiguous. Although it does not explicitly differentiate from siblings, the unique content and context make it distinct.

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 explicit usage guidance: 'Use this for the "do they work in my industry?" question.' This clearly indicates when to use the tool. While it doesn't mention when not to use or provide alternatives, the simplicity of the tool makes this sufficient.

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 full burden and clearly states the tool returns key controls, gotchas, first question, and reference architecture, suggesting a safe read operation without 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 two sentences, front-loaded with purpose, and every sentence adds value without 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?

Given no output schema, the description adequately explains what the tool returns for a query of moderate complexity with 3 parameters.

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%, providing baseline score of 3. Description adds minimal additional meaning beyond the schema's own parameter descriptions, which are already clear.

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 explicitly states the tool returns Agrus's documented position on a specific regulatory regime as it applies to a described AI use case, clearly distinguishing it from sibling tools like get_case_study or list_services.

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 clear context for use ('when a buyer-side AI agent is evaluating Agrus's compliance fluency'), but does not explicitly mention when not to use it or provide 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?

No annotations provided, so description carries full burden. It discloses the workflow: creates a CRM contact, tags lead source, stores verbatim note, and includes human response timing (24 business hours). However, it does not mention potential side effects or cost.

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 no wasted words. Front-loaded with the core action, then proceeds to details and usage guidance. Every sentence adds 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?

Given no output schema, the description adequately covers the process and outcome (human reply by email). It explains the lifecycle from invocation to response. Lacks details on error handling or edge cases, but is sufficient for an AI agent to understand the tool's behavior.

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%, so baseline is 3. The description adds context about how parameters are used (e.g., the note contains scope summary) but does not explain each parameter beyond the schema. It provides a useful overview of the overall process.

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: 'Triggers a formal Agrus proposal workflow.' It specifies the actions (creates contact, tags with lead source, stores scope summary) and distinguishes itself from exploratory scoping by stating 'not for exploratory scoping.' This differentiates it from the sibling tool 'scope_poc'.

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 states when to use: 'when the buyer wants to formally engage Agrus — not for exploratory scoping.' This provides a clear decision rule and contrasts with other tools like scope_poc.

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. It discloses it is read-only (no records created, no contact), output is not binding, and quotes are confirmed on 30-minute scoping calls. Missing details on error handling or limits, but otherwise transparent.

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?

Four sentences, front-loaded with the main action, no filler. Each sentence serves a distinct purpose: stating the function, clarifying non-binding nature, declaring read-only behavior, and providing alternative guidance.

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 tool with 4 parameters, no output schema, and no annotations, the description covers purpose, read-only nature, and differentiation. It briefly mentions the output is a 'ballpark price band' but doesn't detail its format. Generally complete for the complexity level.

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 each parameter is well-documented in the schema. The description does not add additional meaning beyond what the schema provides, so baseline 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 returns a heuristic ballpark price band for an AI deployment (specific verb+resource) and distinguishes itself from request_proposal by being non-binding and for order-of-magnitude pricing.

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 says when to use (order-of-magnitude pricing before committing) and when to use an alternative (request_proposal for tracked requests). Also notes it is read-only and does not contact Agrus.

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 states the tool 'Drafts' and 'Returns' a plan, implying a read-only generative action without side effects. However, it does not explicitly confirm that no records are created or modified, leaving slight ambiguity. A 3 is adequate given the safe tone.

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 short sentences, each adding distinct value: first states the core action, second enumerates return items, third states the usage context. No filler, perfectly front-loaded.

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 adequately lists key return components (3-week plan, team, price band, etc.). It covers the main behavior and inputs. Minor gaps: no mention of error handling or behavior for missing optional params, but overall sufficient for a tool of this complexity.

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 100%, so baseline is 3. The description adds extra guidance for the 'use_case' parameter ('Be specific about workflow, users, and integration surface where possible'), which enhances semantics beyond the schema description. This justifies a 4.

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 ('Drafts') and resource ('Discovery Sprint scope for an AI use case'), and clearly distinguishes from siblings like 'get_case_study' or 'request_quote' by stating it converts a use case into an engagement proposal.

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 states when to use: 'Use this to convert a hypothetical use case into a concrete engagement proposal.' While it doesn't list exclusions, the context of sibling tools provides implicit alternatives for other needs like getting a quote or case study.

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