ReliaQuest GreyMatter MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.6
Disambiguation2/5
With 147 tools, many have overlapping purposes. Singular/plural pairs like `drp_alert`/`drp_alerts` and `watch_drp_alert`/`watch_drp_alerts` create confusion, as do similar actions like `close_case` and `cancel_case`. An agent will struggle to select the correct tool without deep inspection.
Naming Consistency3/5
Most tools follow a snake_case verb_noun pattern (e.g., `create_case`, `update_user`), but there are inconsistencies such as `un_watch` (with underscore), `upsert` variants, and bare-noun queries like `incidents` and `me`. The long compound verb `acknowledge_assign_and_close_incident` also deviates.
Tool Count1/5
147 tools is an extreme number for any MCP server, far exceeding typical scoping. This overwhelms agents and makes selection error-prone.
Completeness5/5
The tool set covers a wide range of GreyMatter capabilities across incidents, cases, tasks, DRP alerts, playbooks, reference lists, and user management, with CRUD and lifecycle operations. The inclusion of a generic `graphql_query` tool fills any remaining gaps, making coverage effectively complete.
Average 2.4/5 across 145 of 147 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 39 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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. It does not state whether the operation is irreversible, what permissions are required, what side effects occur, or what the response contains. The example only shows input variables, not outcomes or implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a raw dump of variable names and a JSON example, with no concise summary, headings, or organization. The opening phrase 'Tasks · mutation unresolveTask' is redundant with the tool name, and the rest is a dense blob that is hard to parse without context. It does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 6 parameters, no annotations, and no output schema, yet the description fails to explain the mutation's effect, the meaning of most parameters, or the expected return value. It is entirely inadequate for an agent to understand and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the descriptions are trivial ('GraphQL: String', 'GraphQL: Int'). The description's example reveals that 'input.taskId' is expected, but the purposes of 'after', 'filter', 'first', and 'order' remain unexplained, and their relevance to an unresolved task mutation is unclear. The example does not compensate for the lack of semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Tasks · mutation unresolveTask', which merely restates the tool name without explaining what the mutation does. It does not use a verb to describe the action (e.g., 'unresolve a task') or distinguish it from sibling tools like 'resolve_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as 'resolve_task' or 'update_task_state'. The description only lists variables and an example, offering no context on appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It fails to mention side effects, required input structure, permissions, idempotency, or any behavior beyond the word 'mutation'. The example variables are for pagination-style queries, which could actually mislead about the mutation's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single unstructured run-on sentence with a long variable list and an incomplete example. It is not front-loaded with a clear purpose, and the truncated example detracts from its usefulness. It could be far more concise while conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, one required, no annotations, and no output schema, the description is severely incomplete. It gives no indication of what the mutation returns, what errors can occur, what the 'input' object should contain, or how the many connection-style variables are used. The description is inadequate for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the schema descriptions are minimal (e.g., just 'GraphQL: CreateUserInput!'). The description simply lists variable names and a cut-off example, without explaining the meaning of the required 'input' parameter or how filter/order parameters relate to a create operation. It adds no useful semantic information over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'User · mutation createUser', which is essentially a restatement of the tool name 'create_user'. It identifies the verb and resource but provides no explanation of what creating a user entails or how it differs from sibling tools like update_user or disable_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description only lists variable names and a truncated example, with no mention of prerequisites, use cases, exclusions, or relationship to other user-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It fails to mention that this is a mutation requiring authorization, whether the action is reversible, or any side effects. The example variables are misleading, suggesting parameters (filter, after, order) that are not part of this mutation's schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but wasteful. The example variables are a large block of irrelevant JSON that distracts from the actual purpose. It lacks a clear, front-loaded definition and instead buries the only useful piece ('Variables: id') in clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with only two parameters and no output schema, the description should still state the action's effect, typical usage, and any required context. The current text is incomplete and misleading, leaving the agent uncertain about what the tool does and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% description coverage for the two parameters, the description's example variables include extraneous fields (filter, after, order) that are not valid for this tool. This actively introduces confusion about the parameter set rather than adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as 'mutation retainIncident' without explaining what retaining an incident does. There is no verb+resource definition beyond the name itself, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like close_incident or acknowledge_incident. There is no mention of the intended workflow or context, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 no behavioral traits: no mention that this is a mutation that modifies data, no permissions needed, no side effects, no return behavior. The bare 'mutation updatePod' implies a write operation but gives no details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a large, unstructured block of variable names and a truncated JSON snippet. It is not front-loaded with a clear statement of purpose; instead it leads with a category label and then dumps an exhaustive list of parameters, which is not concise or well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no output schema, and no annotations, the description is grossly incomplete. It fails to explain the core operation, the required input structure, or how the various filters, order, and pagination parameters interact. The tool cannot be safely invoked based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all parameter names but adds no meaning beyond the schema's type-only descriptions. The 'Example variables' JSON is confusing: it shows filter structures but omits the required 'input' parameter and is truncated. It does not explain how parameters relate to the update operation, making it effectively worthless for building a correct payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely states 'Access Groups · mutation updatePod' which restates the tool name in GraphQL terms with a category label. It does not say what updating a pod entails, what fields can be changed, or how it differs from sibling tools like update_access_group or update_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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, no mention of prerequisites, exclusions, or context. The description is purely a parameter dump with no actionable usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 does not explain what the tool returns, whether it is read-only, how pagination works via the multiple after/first pairs, or what the nested filters represent. The word 'query' hints at a read operation, but the details are entirely omitted, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence that dumps a long list of variable names followed by a truncated example. It is not concise, lacks logical structure, and mixes raw parameter names with example values. This is the opposite of front-loaded, purposeful prose; it reads like an auto-generated metadata dump rather than a crafted tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 18 parameters, one required ID, no output schema, and no annotations. The description offers no explanation of the return value, the significance of the multiple pagination/filter pairs, or the relationship between 'emergencyContact' and the sibling 'emergency_contacts' tool. Given the complexity, this description is severely inadequate for an agent to understand how or when to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are merely GraphQL type references (e.g., 'String', 'Int'), so the description's example variables JSON provides some concrete structure, especially for the 'filter' object. However, the example is truncated and does not explain the meaning of the many repeated parameters (after1, first1, filter1, etc.). Thus, the description adds minimal clarity beyond the schema and fails to adequately compensate for the lack of semantic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'query emergencyContact' which implies a read operation, but it does not explicitly state that this tool fetches a single emergency contact by ID. It lists a large number of variables without clarifying the primary function, and it fails to distinguish itself from the sibling tool 'emergency_contacts' (plural). The purpose is ambiguous and leans toward a generic query rather than a specific, clearly defined operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'emergency_contacts' or 'create_emergency_contact'. There is no mention of context, prerequisites, or exclusions. The description is purely a list of variable names and an example, with no practical instructions for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The only behavioral hint is the word 'mutation', which implies a write operation, but it does not disclose side effects, required permissions, reversibility, or response behavior. The truncated example variables add no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long, auto-generated line that redundantly lists all variables already present in the schema, followed by a truncated JSON example. It is not concise or well-organized; it appears to be raw introspection output rather than a curated explanation, making it hard to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter mutation with no annotations, no output schema, and complex nested filter objects, the description is severely inadequate. It does not explain the purpose of the parameters, what the operation does, when to use it, or what the returned data looks like. The variable list and partial example leave the agent with almost no practical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are only GraphQL type labels (e.g., 'ID!', 'AccessGroupFilter'), which are not semantically meaningful. However, the description's example variables do show the internal structure of nested objects like filter and order, including fields such as customers, ids, name, pods, roles, and users. This adds some practical context beyond the schema, but the example is truncated and many parameters remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'User · mutation enableUser', which merely restates the tool name and labels it as a mutation. It does not use a specific verb to explain what the tool actually does (e.g., 'Enable a user account'). No resource or action is described beyond the name itself, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It does not mention sibling tools like disable_user or update_user, nor does it provide prerequisites, intended scenarios, or exclusions. The description is entirely a variable listing and example, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'query node', which implies a read operation without detailing what is returned, any side effects, permissions, or limitations. It adds no concrete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but poorly structured; it consists of fragments rather than a clear sentence. The leading 'Utilities' adds no value, and the space is not used to convey essential purpose. It is under-specified rather than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is named 'node' and likely represents a generic GraphQL node query, the description is critically incomplete. It lacks any explanation of expected return values, how to find the id, or relationship to other tools. The complete absence of output schema and annotations makes the burden on the description even higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters (100% coverage), so the baseline is 3. The description only repeats 'Variables: id' and provides a placeholder example, adding no meaningful interpretation beyond the schema's 'GraphQL: ID!' hint. It does not clarify what the id represents or how it is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Utilities · query node' is essentially a tautology, restating the tool name 'node' with a generic verb. It does not explain what a node is or what querying it accomplishes, and it does not distinguish this tool from any of the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description is too vague to infer any usage context, and there is no mention of when not to use it or which sibling tools serve similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention whether this is a read-only query, what data it returns, whether it has side effects, or any permissions or error behaviors. The word 'query' implies a read operation, but this is not explicitly stated, and the description does not explain the response structure or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence that dumps a long list of variable names followed by a truncated JSON example. It lacks any structure, front-loading, or summarization. The example is cut off mid-string, making it even less useful. This is far from concise or well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 31 parameters, no output schema, and no annotations, the description is drastically incomplete. It does not explain what a reference list is, what the query returns, how to construct the various filters, or what the required 'id' parameter refers to. The tool is a complex GraphQL query, and the description provides almost no context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are generic GraphQL type references (e.g., 'String', 'Int'), not semantic explanations. The tool description lists parameter names and gives an example filter object, which provides some shape but no meaning for most fields. It does not explain what 'after' and 'first' do, how the multiple filter/order groups (filter1..6, order1..6) relate to each other, or the purpose of 'columnSelector' and 'customer_slug'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reference Lists · query referenceList' but never states what the tool actually does, such as retrieving a reference list by ID. The name 'reference_list' hints at a singular resource, but the description is essentially a label and a list of variables without a clear verb or resource. It does not differentiate from sibling tools like reference_lists or the various reference list mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, what scenarios it fits, or how it differs from alternatives. The description merely lists parameters and provides an example. Sibling tools like 'reference_lists' (likely plural query) and 'create_reference_list' exist, but no comparison or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any behavioral traits such as side effects, permission requirements, return values, or error conditions. The only hint is 'mutation', which is derived from the name itself rather than an explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a cluttered dump of parameter names and a long, truncated example. It repeats schema information without adding useful structure or front-loaded purpose. A minimal, focused explanation would be more concise and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no annotations, and no output schema, the description provides almost no operational context. It never explains what resending an invite means, when it should be called, or what the expected outcome is, making the tool effectively unusable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists variable names and provides an example, but the example is truncated and does not clarify the purpose of the many filter/order parameters. The required 'user' parameter is not semantically explained beyond the schema's type label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and operation type ('User · mutation resendInvite'), with no explanation of what resending an invite actually does. It fails to provide a specific verb+resource purpose and does not distinguish from sibling user-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or any exclusions, leaving the agent without any decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 behavior. It says nothing about side effects, whether this is a write operation, required permissions, or consequences of assignment. The example variables imply a bulk assignment operation, but no explicit behavioral disclosure is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense string that mixes a technical identifier with a truncated example. It is not front-loaded with a clear purpose statement and is not structured in a scannable way. It is under-specified rather than concise; the space is not used to communicate essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex bulk assignment tool with no annotations, no output schema, and only a cryptic input schema. The description fails to explain the return value, the required fields within 'input', error conditions, or how the 'filter' controls which alerts are assigned. It is wholly inadequate for an agent to reliably invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has descriptions for both parameters, the 'input' description is just a GraphQL type reference ('DRPAlertBulkAssignmentInput!'), and 'customer_slug' is an optional header override. The example variables add some concrete field names (assignee, comment, filter, etc.), but these are not explained semantically. An agent would struggle to understand that 'assignees' within the filter determines assignment targets or what 'includeUnassigned' does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the mutation name ('DRP Alerts · mutation assignDRPAlerts') and provides a variable example. It does not explain in plain language that this tool assigns DRP alerts to an assignee, nor does it distinguish its purpose from the singular 'assign_drp_alert' sibling. This is essentially a tautology of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 presence of both 'assign_drp_alert' and 'assign_drp_alerts' siblings creates ambiguity, but the description offers no hint about bulk vs. single assignment or which one to choose in which situation. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states 'mutation' (a trivial fact already implied by the name) and gives no details on side effects, required permissions, reversibility, or return behavior. The description is essentially empty of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bloated dump of variable names followed by a long, truncated JSON example. It is not front-loaded with the core purpose, and much of the content is irrelevant or confusing. It would be far more concise to simply say 'Creates a pod' and describe the input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter mutation with no output schema, this description is grossly incomplete. It does not explain what a pod is, what fields the input requires, what the mutation returns, or any prerequisites. The misleading example further detracts from completeness, making the tool nearly impossible to use correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are just GraphQL type names (e.g., 'GraphQL: String'), which provide no domain meaning. The description lists 15 variable names but does not explain their roles, and the required 'input' parameter is not described at all. The example variables are irrelevant to a create mutation, failing to compensate for the schema's deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Access Groups · mutation createPod', which essentially restates the tool name without explaining what a pod is or what the mutation does. The 'Access Groups' prefix adds confusion rather than clarity, and there is no differentiation from sibling tools like create_access_group or update_pod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 example variables shown correspond to a query (with pagination and filters), not a mutation, which is misleading and could lead the agent to use it incorrectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides no behavioral details: no mention of side effects, permissions, whether it overwrites existing lists, or what response to expect. Calling it a 'mutation' only implies a write, which 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specifies, not truly concise. It includes a variable list and an example that is cut off, providing no coherent structure or useful content. Every sentence should serve a purpose, and this does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations, yet the description gives no overview of the operation's purpose, expected behavior, or result. Given the complexity of creating a reference list (with columnSelector, filter, order, input), the description is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists variable names but does not explain their purpose or format beyond what the schema already provides. The example variables give some hint but are truncated and not explained. The schema descriptions ('GraphQL: String') are minimal, so the description fails to add meaningful semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the mutation name 'createReferenceList' with no verb phrase or explanation of what a reference list is or what creation entails. It does not clearly state the tool's function, making it a near-tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools for reference lists (update_reference_list, delete_reference_list, create_reference_list_row, etc.). There is no mention of prerequisites or intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'mutation', which is a GraphQL type, not a behavioral explanation. It does not describe what disabling a user entails, whether it is reversible, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense block listing variables and a long example. It lacks clear structure and includes redundant information already present in the schema. The front-loaded 'User · mutation disableUser' is minimal but the remainder is clutter rather than useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, no output schema, and no annotations, this description is grossly inadequate. It fails to explain the core operation, the meaning of most parameters, or any behavioral implications. The example variables are truncated and cryptic, leaving the agent without enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all parameter names and provides an example object, but it does not explain the meaning of any parameter. The schema itself only provides GraphQL type names (e.g., 'ID!', 'String'), which are not semantically helpful. The example offers some structural hints but falls far short of clarifying the purpose of each parameter, especially the many filter/order pairs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'mutation disableUser' which essentially restates the tool name. It gives no explicit statement of what the tool does, such as 'Disables a user account'. It is a tautology rather than a meaningful explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like enable_user, delete_user, or update_user. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only includes the word 'query,' which implies a read operation, but it does not state side effects, pagination details, rate limits, or what the response contains. The description provides essentially no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long, comma-separated enumeration of 38 variables followed by an example, forming a wall of text. It is not structured for quick comprehension, and much of the content redundantly duplicates the schema. This is over-specification without informative structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 38 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain the purpose of the 'by' parameter, the meaning of the numbered filter/order groups, or what data is returned. The tool appears complex, and the description fails to provide the needed context for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions are merely GraphQL type references (e.g., 'GraphQL: DiscoverTaskBy!') and do not explain meaning. The description lists all parameter names and provides a truncated JSON example showing the structure of filter/order, which offers a little value. However, the required 'by' parameter remains unexplained, and the example is incomplete, so the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Discover Tasks · query discoverTask,' which essentially restates the tool name and does not explain what the tool actually does. The rest is a list of variable names and a truncated JSON example, adding no functional clarity. It fails to distinguish it from sibling tools like discover_tasks, task, or tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use discover_task versus other task-related tools. The description does not mention alternatives, prerequisites, or typical use cases, leaving the agent with no information about appropriate invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. It only notes that this is a mutation, implying a change, but gives no details about side effects, permissions, reversibility, or what 'releasing' an incident entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is only one line, but it is followed by a large example variables block full of irrelevant fields. This is not concise and detracts from the actual parameter information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no annotations and no output schema, the description is almost entirely empty of behavioral context. It never explains what release_incident does, when to use it, or what the outcome is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (id and customer_slug), so the baseline is 3. However, the description's example variables block includes fields not present in the schema (filter, after, first, etc.), which is misleading and adds confusion rather than clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says "Incidents · mutation releaseIncident", which is essentially a restatement of the tool's name and domain. It does not explain what 'release' means in this context or how it differs from sibling tools like close_incident or unresolve_incident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description lacks any mention of when to use this tool, what prerequisites exist, or which alternatives might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It fails to mention whether this is a read-only operation, what the response contains, pagination semantics, or any side effects. It simply lists variable names and an example without explaining the query's behavior or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not well-structured: it starts with a cryptic fragment, then a flat list of variables, then a truncated example. It lacks a clear, front-loaded statement of purpose. While it is not overly long, it is inefficient because most of the text is a mechanical replay of schema variable names with minimal explanatory value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters, nested GraphQL types, and no output schema, yet the description does not explain return values, filtering semantics, pagination, or the relationship to Access Groups. The example is complex but unexplained, and there is no mention of authorization or response format. The description is far from adequate for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only GraphQL type names (e.g., 'String', 'Int'), which are unhelpful. The description adds an example showing nested filter structures, but it does not explain what each field (e.g., 'after', 'filter', 'order') actually does. The variable names are repeated, and the example is truncated, providing only marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Access Groups · query role', which identifies a resource and a generic action, but is ambiguous. It does not clearly explain what the query returns or how it differs from sibling tools like 'roles', 'access_group', or 'access_groups'. The phrase 'query role' is a fragment rather than a full statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It does not mention prerequisites, when to choose 'role' over 'roles' or 'access_group', or any constraints. The description only lists variables and an example, leaving the user to infer the tool's intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention any side effects, permissions, reversibility, return values, or how the mutation affects existing data. The raw variable listing and truncated example offer no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a disorganized dump of variable names and a cut-off example. It is not front-loaded or concise; it is cluttered and fails to provide a clean summary of what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters, no annotations, and no output schema, the description is severely inadequate. It does not explain the intended structure of 'input', the purpose of the multiple filters and orders, or what a successful response looks like. The agent is left with almost no actionable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage but only with generic type descriptions (e.g., 'GraphQL: String'). The description lists the variable names, which duplicates the schema, and provides an example that is truncated. It does not explain the purpose of each parameter or how they relate, leaving ambiguity around terms like 'filter', 'filter1', and 'filter2'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Access Groups · mutation updateAccessGroup' which essentially restates the tool name. It doesn't explicitly state that this tool updates an access group or what that entails. There is no natural-language explanation of the operation, making it nearly a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like create_access_group or delete_access_group. The description gives no context on prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It never explains what the mutation does, what side effects occur, what permissions are needed, or what the return value looks like. The only behavioral hint is the word 'mutation' and the example input with 'newState', which 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not a well-structured human-readable explanation. It begins with a context label, lists variable names redundantly, and then dumps a large JSON example. While the example is potentially useful, the overall format is clunky and does not use concise prose to convey meaning efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a 6-parameter mutation with no output schema and no annotations. It fails to explain the tool's behavior, response format, or how parameters interact. An agent would be unable to use this tool correctly without significant additional inference or trial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% description coverage, each description is only 'GraphQL: String' or similar, providing no semantic meaning. The description does not explain the parameters beyond listing them and giving one example. The example clarifies that 'input' contains 'newState' and 'taskId', but the roles of 'after', 'filter', 'first', and 'order' remain unexplained, and the parameter descriptions do not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a schema dump: 'Tasks · mutation updateTaskState. Variables: ...' It does not explicitly state that the tool updates a task's state. The example input shows 'newState' and 'taskId', which lets an agent infer the purpose, but the description itself is tautological (restates the tool name) and lacks a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool versus alternatives like update_drp_alert_state, update_incident_state, or update_discover_task_state. There is no mention of prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses nothing about side effects, required permissions, what the mutation changes, or any behavioral traits. The mutation name implies a subscription/watch operation, but no details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on block of variable names and a partial example. It is not front-loaded or structured; it reads as a technical dump rather than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 14 parameters and no output schema or annotations. The description provides no information about return values, pagination, error conditions, or the effect of the mutation. It is wholly inadequate 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds minimal value. It lists variable names already present in the schema and shows a truncated example without explaining what each filter field means or how parameters relate to different resource types. The example is cryptic and incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'mutation watchDRPAlert' and lists variable names, never explaining that this tool watches a DRP alert. The name itself is slightly clearer, but the description is essentially a tautology and does not differentiate from siblings like watch_drp_alerts or un_watch_drp_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement about when to use this tool, what problem it solves, or how it compares to alternative tools. No context is provided beyond the raw GraphQL mutation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only labels the operation as a 'mutation'. It does not disclose side effects, reversibility, permissions, or consequences of unassigning. The example variables ('comment', 'shortCode') are not explained, so the behavioral impact remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with domain and mutation name, with an example payload following. It is not verbose, but the brevity sacrifices necessary information. It reads more like a code comment than an explanatory description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a nested input type. The description fails to explain the tool's purpose, usage context, or input field semantics. Given the complexity and lack of structured metadata, the description is clearly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'input' only as a GraphQL type without field details. The description adds an example structure with 'comment' and 'shortCode', which gives a hint but not meaning. The optional 'customer_slug' override is not covered in the description. Thus, the description adds some practical example value but fails to explain what the fields actually do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'DRP Alerts · mutation unassignDRPAlert' restates the tool name and identifies it as a mutation, but lacks a plain-language statement of what it does. It does not distinguish from the sibling 'unassign_drp_alerts' (plural), so the agent cannot tell when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'unassign_drp_alerts' or 'assign_drp_alert'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It merely calls the operation a 'mutation', but gives no details about side effects, required permissions, error behavior, or return values. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single unstructured line mixing the operation name, variable list, and JSON example. It front-loads no useful purpose and repeats information already present in the schema. The variable enumeration is redundant, and the example is not clearly separated or explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, this description provides almost no context. It doesn't explain what the tool does, when to use it, what the parameters mean, or what output to expect. It is merely a GraphQL operation template, far from sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal ('GraphQL: String'), but the description includes an example with placeholder values for all parameters, including the input object's fields (accessGroups, customerId, description, name, resource, users). This adds some structural guidance, yet leaves parameters like after, first, notFilter, and order unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'DRP Access Control · mutation createAccessControlPolicy', which essentially restates the tool name without explaining what it does. It does not provide a plain-language purpose or distinguish the tool from siblings like update_access_control_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 description only lists variables and an example payload, with no mention of prerequisites, use cases, or when to choose another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, irreversibility, or any outcomes beyond the example input. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and lacks structure. It is essentially a code snippet without a plain-language explanation. This is under-specification rather than concise, as it does not efficiently convey key information that an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema and no annotations, yet the description does not cover return values, errors, prerequisites, or any operational context. It is completely inadequate 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema's 'input' description is generic ('GraphQL: CreateReferenceListColumnInput!'), the description provides an example variable structure with fields like name, referenceList, and type, which adds some meaning. However, the example uses empty strings and does not fully explain each field's purpose. With schema coverage at 100%, a baseline of 3 is appropriate given the minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reference Lists · mutation createReferenceListColumn' essentially restates the tool name and provides a GraphQL mutation reference. It gives no plain-language explanation of what the tool does, though the example variables hint at creating a column in a reference list. This is a tautology of the name with minimal added context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_reference_list_row or update_reference_list_column. The description contains only a technical reference and example variables, with no context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention side effects, permissions, rate limits, return format, or any runtime behavior. The description is purely a terse command with no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks necessary information and structure; the 'Data ·' prefix and example are fragmented rather than organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and only cryptic parameter descriptions. The description fails to explain what the tool returns, when to use it, or what the 'by' filter affects. It is not sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a concrete example for the 'by' parameter, showing it accepts an object with 'incidentId', which provides some meaning beyond the schema's 'GraphQL: DataBy!' type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Data · query dataSourceSchema' essentially restates the tool name with a verb. It does not explain what a dataSourceSchema is or what the query returns. The example variable 'by' hints at incident association but does not clarify the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only shows a variable example and gives no context on use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose the destructive nature, side effects, return values, or any behavioral traits. The inclusion of pagination variables (after, first, order) for a delete mutation adds confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured. It is a run-on list of variables and an example, with no clear purpose statement or logical grouping. The long example JSON is not well integrated and the text is not front-loaded with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is extremely inadequate. It does not explain required vs optional parameters, what the delete operation does, or what response to expect. The 9-parameter surface with only 1 required parameter is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 an example JSON showing the structure for 'notFilter' and 'order', which provides some semantic value beyond type-only schema descriptions. However, it does not explain why pagination variables are present or how they relate to deletion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only 'DRP Access Control · mutation deleteAccessControlPolicy' which restates the tool name in GraphQL mutation form. It does not explicitly state that this tool deletes an access control policy, relying on the name rather than explaining the action or resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like update_access_control_policy or delete_access_group. There is no mention of prerequisites, alternatives, or context for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description provides no behavioral details such as whether deletion is destructive, irreversible, or requires specific permissions. It merely names the mutation and its input variables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a verbose dump of variable names and an example, lacking a clear front-loaded purpose. It is cluttered and not concise despite being a single block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no behavioral context, the description is incomplete for a mutation that appears to delete a reference list. It does not mention return values, side effects, or how the listed variables interact, making it inadequate for a tool with seven parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema covers all parameters with basic GraphQL type descriptions, the tool description's example variable JSON demonstrates the expected structure, offering some practical guidance. However, semantic meaning (e.g., that 'id' is the list to delete, or why pagination fields are present) is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reference Lists · mutation deleteReferenceList' essentially reiterates the tool's name without explicitly stating that it deletes a reference list. It fails to define the operation's effect, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like delete_reference_list_row or update_reference_list. The description only lists variables and an example payload, offering no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'query', implying a read operation, but does not state whether it is read-only, describe pagination behavior, or explain the meaning of the various after/filter/first/order groups. The example variables hint at structure but do not disclose side effects, auth requirements, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long, unstructured dump of variable names and an example JSON, most of which repeats schema property names. It is not concise and the example is cut off mid-sentence. The front-loaded label 'Discover Tasks · query discoverTasks' is unhelpful, and the rest does not earn its space with meaningful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex GraphQL tool with 13 parameters, no output schema, and no annotations. The description fails to explain the meaning of after/filter/first/order groups, the relationship between the three sets of variables, return values, or expected use cases. It is far from complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (each parameter is documented with a type name like 'GraphQL: String'), so the baseline is 3. The description lists all variable names and provides a partial example that shows filter and order shapes, which adds some value beyond the schema's bare type references. However, the example is truncated and does not explain the semantics of each parameter group, so it only marginally compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Discover Tasks · query discoverTasks', which essentially restates the tool name and identifies it as a GraphQL query. It does not explain what the tool does, what tasks are discovered, or what it returns. Compared to siblings like 'discover_task', the plural form hints at listing, but the purpose is not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like discover_task, assign_discover_task, or close_discover_task. The description does not mention any prerequisites, exclusions, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'query', which implies a read-only operation, but does not disclose nested behavior, return shape, authentication needs, or rate limits. The example variables hint at complex filtering and pagination but without explanation, leaving the agent to guess what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a poorly structured wall of text. It begins with a short phrase, then dumps a redundant variable list (duplicating the schema) and a massively long example with repeated placeholders. This is not concise and makes it harder for an agent to extract key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 30 parameters, high complexity, and no output schema, a complete description is essential. This description provides almost no context: no explanation of what a playbook run is, what the query returns, how the nested connections relate, or what to do with the 'id' parameter. It is far from sufficient for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are just GraphQL type names (e.g., 'AccessGroupFilter'), so they convey limited semantics. The description adds a detailed example showing the structure of filter objects and order objects, which is valuable for constructing arguments. However, it does not explain the meaning or purpose of each variable beyond the example, so it only partially compensates for the shallow schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query playbookRun', which is little more than a restatement of the tool name. It doesn't explain what a playbook run is, what the query returns, or whether it fetches a single item or a list. The mention of 'id' suggests a single resource, but the many pagination variables imply nested lists, creating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus its siblings like 'playbook_runs' or 'run_playbook'. There are no explicit alternatives, prerequisites, or contextual cues. The description is purely declarative and offers no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. It fails to do so: it does not state that this is a read-only query, what data it returns, how pagination works (beyond listing 'after' and 'first'), or any side effects. The word 'query' implies a read operation, but no behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense dump of variable names followed by a long example JSON that gets truncated mid-object. It is not well-structured or front-loaded with a purpose. The example consumes space without completing, and the variable list largely repeats schema information. A concise summary and clearer structure would be more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain what 'playbookRunFilterData' represents, how the filters combine, what the return shape is, or why the three sets of filter/order variables exist. An agent cannot reliably determine when to use this tool or what to do with its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal (e.g., 'GraphQL: String'), but the description adds some semantics by showing an example structure for 'filter' and 'order', including keys like customers, ids, name, pods, roles, and users. However, the example is truncated and covers only a subset of the 13 parameters; many parameters (e.g., after1, filter1, order1, after2) are only listed by name without explanation, so the added value is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Playbooks · query playbookRunFilterData' and lists variable names, which is essentially a restatement of the tool name. It does not provide a human-readable statement of what the tool does (e.g., 'fetch filtered playbook runs'). The example variables hint at filtering, but the purpose remains ambiguous and does not distinguish it from siblings like 'playbook_runs' or 'run_playbook'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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, when not to use it, or how it compares to alternatives. The description simply enumerates parameters and an example. It does not mention any conditions, prerequisites, or a preferred scenario for invoking this tool over sibling tools like 'playbook_runs' or 'playbook_run'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists variables and an example, without explaining return format, side effects, required permissions, or pagination behavior. This is a significant gap for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not well-structured. The variable list is redundant with the schema, and the example is cut off mid-way, making it less useful. It is under-specified rather than concise, lacking clarity and organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no annotations), this description is grossly inadequate. It does not explain the core purpose, expected inputs/outputs, or any behavioral nuances, making it nearly impossible for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are essentially type-only ('GraphQL: String'), but the example in the description provides meaningful structure for the filter object, showing fields like customers, ids, name, pods, roles, and users. This adds some value beyond the schema, though it is truncated and unclear for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Access Groups · query pod' is vague and generic. 'query pod' essentially restates the tool name, and the mention of 'Access Groups' does not clarify the exact operation. It fails to distinguish this tool from siblings like 'pods', 'access_group', or 'create_pod'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 alternatives. There is no mention of context, prerequisites, or excluded scenarios, leaving the agent without any indication of appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 does not mention pagination behavior, access requirements, rate limits, or return format. Listing variables without explaining their effect or what the query does 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single unformatted line that mixes a category label, variable names, and an example. It is under-specified rather than concise, lacking clear structure or prioritized information. It does not earn its place as a helpful guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, a required 'by' field, no output schema, and no annotations, the description is critically incomplete. It does not explain what the query returns, how pagination works via 'after'/'first', or when to use this tool. An agent cannot reliably select or invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has a GraphQL type description), meeting the high-coverage baseline of 3. The tool description adds a concrete example of variable values, which helps illustrate structure, but it does not explain the semantic meaning of each parameter beyond what the schema already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('query searchHistory') and adds a vague category 'Query Management' without specifying what history is searched or what the query returns. It does not distinguish this tool from sibling tools like 'incident' or 'case'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 alternatives, no context, prerequisites, or exclusions. The example variables give a partial usage pattern but no explanation of scenarios where this should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits such as side effects, bulk behavior, permissions, or return format. The example variables are truncated and do not convey behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not well-structured; it leads with a label and then dumps a long, truncated JSON example. It lacks a clear opening purpose statement and is neither concise nor front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is severely incomplete. It does not state what the operation does, what the filter is for, or what the response looks like, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing descriptions for both 'input' and 'customer_slug'. The description adds a partial example of the input structure, but it is truncated and lacks explanation, so it does not go beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially 'DRP Alerts · mutation unassignDRPAlerts', which restates the tool name as a GraphQL mutation and doesn't explain what the tool does in plain language. It does not distinguish between the sibling 'unassign_drp_alert' (singular) and this plural version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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, prerequisites, or alternatives. The sibling list includes unassign_drp_alert, but the description provides no differentiation or contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it says nothing about side effects, permissions, or whether the incident must be currently resolved. The example variables are the only behavioral clue and are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The prose portion is minimal but is followed by a large example block filled with extraneous variables. The description is not well-structured or front-loaded; it opens with a tautological phrase rather than a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing mutation with no annotations, no output schema, and no description of behavior, constraints, or side effects. The provided information is far from sufficient for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only labels input as 'GraphQL: UnresolveIncidentInput!', but the description's example adds incidentId and reason fields, which provides useful parameter context. However, the example is cluttered with many irrelevant variables (filter, after, first, order), which could mislead an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the operation name as 'mutation unresolveIncident' without explaining that it changes an incident's resolved status. The example variables hint at incidentId and reason, but the core purpose is not explicitly stated and there's no differentiation from sibling incident mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like close_incident, update_incident_state, or unresolve_task. There is no mention of prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only labels the operation as a 'mutation' but does not explain what un-watching does, whether it is reversible, permission requirements, or side effects. No informational value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one line), but this is under-specification rather than effective conciseness. It lacks essential information and does not adequately serve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with two parameters and no output schema, the description is grossly incomplete. It fails to explain the tool's core purpose or provide any behavioral context, leaving the agent without sufficient information to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions), so a baseline of 3 applies. The description adds only 'Variables: shortCode' and an example, which does not enrich the semantics of shortCode or customer_slug beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name and GraphQL mutation ('unWatchDRPAlert') without explicitly stating the action ('unwatch a DRP alert'). It provides no verb+resource clarity beyond what the name already implies, making it a near-tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as un_watch_drp_alerts (plural) or watch_drp_alert. There is no context, prerequisite, or exclusion information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 side effects, permissions, overwrite semantics, or any other behavioral aspects. The example variables hint at fields but not at what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It reads like a raw code comment or snippet, lacking structured explanation. The example is useful but the overall presentation is cryptic and not well-structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema, and the description is far too minimal. It does not explain return values, required permissions, side effects, or when to use it. The presence of many related sibling tools further highlights the need for contextual guidance, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for the two parameters are minimal (input is just a GraphQL type, customer_slug provides a header override explanation). The description adds an example input object showing fields like id, note, and rqAllowedToRun, which provides some structural insight beyond the schema. With 100% schema coverage, this meets the baseline 3, but the description does not explain the meaning or usage of these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially repeats the mutation name ('upsertCustomerPlaybook') and labels it as a GraphQL mutation, without explaining what the tool does in plain language. 'Upsert' suggests create-or-update, but the resource and effect are not clarified, making it vague and not distinguishing it from sibling tools like 'upsert_playbook_metadata'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 description only provides a mutation name and example variables, with no context about typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. It does not explain effects beyond 'mutation', such as whether the operation is reversible, what permissions are required, failure handling, or any side effects. The provided variables only list field names without explaining their behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The prose is minimal but the example variables form a long, truncated block that dumps fields without explanation or structure. The description is not a clean, front-loaded summary; it mixes a terse mutation label with a messy example that is cut off mid-way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex bulk mutation tool with no output schema and no annotations. The description fails to specify what state is actually being updated (e.g., open/closed), how the filter interacts with the update, or the return value. It is severely incomplete for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'input' as 'GraphQL: BulkUpdateDrpAlertStateInput!', which is unhelpful. The description's example variables add real meaning by enumerating filter fields (active, alertExternalIds, alertFingerprints, assetLabelIds, etc.) and showing the 'comment' field, giving an agent a concrete sense of the expected input structure beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool's name as 'mutation bulkUpdateDrpAlertState' without a clear verb-object statement of what the tool does. The example variables hint at filtering and a comment, but the purpose (updating state of multiple DRP alerts) is only inferable from the tool name itself, not the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_drp_alert_state for single alerts or bulk_close_drp_alerts for closing. The description offers no context on prerequisites, filtering considerations, or scenarios where bulk mutation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must explain behavioral traits. It only labels the operation as a 'mutation' and provides an example input, but does not disclose side effects, required permissions, reversibility, or the consequences of modifying linkedFields. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but that brevity comes from being a raw GraphQL introspection stub, not from well-crafted concise language. It lacks a plain-language summary and dumps a JSON example without context, making it under-specified rather than effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation with a nested input object and no output schema, so the description should cover broader context like return behavior, side effects, or usage scenarios. It only provides a partial example and no explanation of the operation's effect, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives a generic 'GraphQL: UpdateReferenceListColumnInput!' for the input parameter and a clear description for customer_slug. The description adds an example input object showing fields (id, name, description, linkedFields with add/remove/replace), which provides structural insight beyond the schema. However, it does not explain the meaning or constraints of these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reference Lists · mutation updateReferenceListColumn', which simply restates the tool name with a domain prefix. It does not explicitly say what the mutation does (e.g., 'Updates a column in a reference list'), and the example variables are the only hint of behavior. This is barely above a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 related siblings like create_reference_list_column, delete_reference_list_column, or update_reference_list_row. The description provides no context about the operation's role in managing reference lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it only mentions that this is a mutation. It does not disclose side effects, permissions required, whether it creates subscriptions or notifications, or any impact on alert state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is poorly structured and includes a large JSON snippet that is cut off mid-way. The opening 'DRP Alerts · mutation watchDRPAlerts' is uninformative, and the example takes up space without a clear explanation or complete context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should explain the operation's purpose, behavior, and return value. None of this is present; it is only a raw GraphQL fragment with an example input. The description is far from complete for a bulk mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type-level descriptions (e.g., 'GraphQL: DRPAlertBulkWatchInput!'), but the description adds a concrete example variable showing nested filters like alertExternalIds, assetTypes, and assignees. This example gives meaningful structure beyond the schema, though it is truncated and not fully explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and GraphQL mutation name ('watchDRPAlerts') without explaining what 'watching' an alert means or what the tool does. It is essentially a tautology, repeating the name and type rather than providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus its alternatives like watch_drp_alert, un_watch_drp_alert, or un_watch_drp_alerts. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'query accessGroup' and lists variables, not mentioning the response shape, pagination behavior, permissions, or nested resources. This is insufficient for a 14-parameter GraphQL query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not well-structured. It is a fragment followed by a variable list and a truncated example. While it avoids verbosity, it under-specifies the tool's purpose and usage, making it more under-specified than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, no output schema, and no annotations, this description is completely inadequate. It does not explain what the query does, how parameters interrelate, or what the response contains. The example variables hint at some structure but are incomplete and cut off.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are minimal ('GraphQL: String', etc.), but coverage is 100%. The description adds a truncated example variables object showing filter structure ('accessGroups', 'customers', 'ids', 'name', 'roles', 'users'), which provides some semantics beyond the schema. However, most parameters (after, first, order, etc.) remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Access Groups · query accessGroup', which essentially restates the tool name as a GraphQL field. It fails to specify that this tool retrieves a single access group by ID or explain what it returns. No differentiation from sibling tools like access_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as access_groups (list) or create/update/delete tools. The required 'id' parameter implicitly suggests fetching a specific access group, but this is never stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is entirely responsible for disclosing behavior. It fails to state what 'closing' an alert entails, whether a comment is added (the example includes a 'comment' field), any side effects, or required permissions. The only behavioral hint is the tool name itself, which 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and structurally clean, but it is under-specified rather than appropriately concise. The phrase 'mutation bulkCloseDrpAlerts' is redundant with the tool name, and the example JSON consumes space without conveying purpose. It omits essential information, making it poorly sized for the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a nested input type, the description needed to explain behavior, input semantics, and expected results. It does none of this. The description is a stub that leaves the agent with only the name and an example, which is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes customer_slug but only references a GraphQL type for 'input', offering little semantic meaning. The description's example adds concrete fields (drpAlertIds and comment), which is helpful for understanding the expected structure. However, it does not explain what these fields do or their constraints, so it only partially compensates for the schema's opacity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply states 'mutation bulkCloseDrpAlerts', which is essentially the camelCase version of the tool name. It does not explicitly say the tool closes DRP alerts in bulk, nor does it differentiate from sibling tools like bulk_update_drp_alert_state or bulk_add_drp_alert_comment. The example variables hint at the input shape but do not clarify the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of prerequisites, and no explanation of whether it's intended for closing multiple alerts as opposed to using individual alert updates or bulk state changes. The description provides no contextual or exclusionary information to aid decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full responsibility for disclosing behavioral traits. It labels the operation as a 'mutation' but does not state that it creates a new access group, what permissions are required, whether it is reversible, or what side effects occur. The parameter list adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a raw dump of GraphQL variable names and a long example JSON, without a clear, front-loaded purpose statement. It is not well-structured for quick comprehension and redundantly lists parameter names that are already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with 14 parameters, no annotations, and no output schema, the description is severely inadequate. It fails to explain the tool's function, appropriate usage, or behavioral consequences. The auto-generated GraphQL information does not provide the necessary context for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 14 parameters have schema descriptions (100% coverage), so the baseline is 3. The description does list the parameter names and an example variables object, but these names are already in the schema and the example is truncated and unexplained, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: 'Access Groups · mutation createAccessGroup.' It does not explain in plain language that this tool creates an access group. The phrase 'mutation createAccessGroup' is a tautology of the name 'create_access_group' and provides no additional clarity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like update_access_group or delete_access_group. It only lists parameters and example variables, with no mention of the appropriate context or scenarios where this mutation should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only says 'mutation,' which is already implicit in the name, and offers no additional context about permissions, side effects, idempotency, error cases, or what happens after creation. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with 'Detections · mutation createActivityLogEntryComment,' followed by an example. It is not verbose, but the fragmented structure reads more like raw metadata than a human-usable explanation. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an opaque nested input, this description is severely incomplete. It lacks usage context, behavioral details, parameter requirements for the nested object, and any sense of expected outcome. The example is the only useful piece, but it is far from sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the top-level 'comment' parameter as an opaque GraphQL input type, so the example variables '{"comment":{"activityLogEntryId":"<ID HERE>","text":""}}' add meaningful structure by revealing the nested fields. This compensates for the schema's lack of nested detail. The second parameter, customer_slug, is adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: 'mutation createActivityLogEntryComment.' It provides no natural-language definition of what the tool does beyond the name and an example variable. The example hints that it creates a comment on an activity log entry, but the description itself is tautological rather than explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 its many comment-related siblings (add_case_comment, add_drp_alert_comment, add_incident_comment, etc.). No context, prerequisites, or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only labels it as a 'mutation' without disclosing side effects, whether it sends an email, how the generated link behaves, expiration, or required permissions. The description carries the full burden and fails to provide any behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with a variable list and a long truncated example, making it difficult to parse. It lacks clear structure, and the example is cut off mid-sentence, reducing usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation with 14 parameters, no annotations, and no output schema, yet the description only provides a name and a parameter dump. It does not explain the tool's purpose, outcomes, or edge cases, making it clearly insufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 14 parameters, but they are only GraphQL type labels (e.g., 'GraphQL: String' or 'GraphQL: ID!') that don't convey semantic meaning. The description adds an example JSON with filter structure, which gives some context, but the example is truncated and many nested types remain unexplained. Since coverage is technically 100%, the baseline is 3, and the example provides marginal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name as 'mutation generatePasswordLink' and adds no verb or resource explanation. It lists variables and an example but never says what the tool actually does (e.g., generate a password reset link for a user). This is essentially a tautology with some parameter metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No context is provided about when to use this tool over related user-management tools (e.g., resend_invite, send_forgot_password, update_user). There are no alternatives, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavior, but it discloses nothing beyond the fact that it is a query. It does not state whether it is read-only, how pagination works, what the filters do, or what the response contains. The example variables show structure but do not describe behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes a concrete example, but it is also under-specified. The raw list of variables duplicates the schema, and the example is not explained. Its brevity is not an asset because critical information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain the query's purpose, return shape, or how to use the parameters effectively. The tool name 'integration' and sibling context do not compensate for the absence of essential usage information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds an example JSON that illustrates the structure for 'after', 'filter', 'first', 'order' and nested pagination parameters, which is useful for invocation. However, it does not explain the meaning of each parameter beyond the raw variable names and GraphQL type placeholders.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives the vague phrase 'Query Management · query integration' which essentially restates the tool name without specifying the resource or operation. It does not say what is being queried, what data is returned, or how this relates to the 'integrations' sibling tool. The example variables hint at an integration activity log query but the purpose is never stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'integrations' or 'graphql_query'. The description only lists variables and an example payload, with no mention of appropriate scenarios, prerequisites, or exclusions. No usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but does not. It only states 'query permissions', which implies a read operation but offers no detail on side effects, authentication, rate limits, or the structure of results. This is a minimal and uninformative description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity is outweighed by under-specification. The phrase 'Example variables: {}' adds no value and seems like placeholders. The structure is not front-loaded with key information; it is just cryptic fragments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools and no output schema, the description is severely incomplete. It does not explain what the permission query returns, how to filter or scope results, or what makes this tool distinct from related access group tools. The agent cannot reliably select or invoke this tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter 'customer_slug' with a clear purpose ('Override the x-reliaquest-customer (OpCo) header'). Since schema coverage is 100%, the baseline for this dimension is 3. The description adds no parameter-level meaning, but the schema already carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Access Groups · query permissions' mentions a verb and resource but is vague. It does not clarify what specific permission querying is performed or how it relates to the many sibling tools like 'access_group' and 'access_groups'. The dot-separated prefix 'Access Groups' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The phrase 'query permissions' implies a use case but provides no context, prerequisites, or exclusions, and sibling differentiation is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only says 'mutation,' which is already implied by the tool type, and does not explain what happens to failed tasks, side effects, authorization requirements, or rate limits. The description is virtually empty of behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but poorly structured: it reads as a label plus variable list rather than a coherent explanation. Every word is not earning its place because the format leaves out a clear statement of the tool's function. This is under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: it does not state the expected outcome, that only failed tasks are affected, return values, or any prerequisites. With no annotations and no output schema, the description is far too incomplete for an agent to understand the tool's effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters. The description repeats playbookRunId with an example but does not add semantic meaning beyond the schema. The schema's description of playbookRunId is minimal ('GraphQL: ID!'), yet the description text does not elaborate either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category label and the operation name, essentially restating the tool name without explaining that it reruns all failed tasks for a playbook run. It does not add clarity beyond the name itself and fails to distinguish from siblings like run_playbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no context about prerequisites, and no mention of exclusions. Sibling tools like run_playbook or playbook_run are not referenced, so an agent receives no help in selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states 'User · mutation resetMfa.' This confirms it is a mutation but fails to describe what gets changed, whether it is destructive, what prerequisites exist, or what the response contains. The example variables are raw data, not behavioral explanations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured, starting with a cryptic header, then a flat variable list, and a truncated example that runs on. The example is not formatted clearly and the cut-off text adds noise rather than helping the agent understand the request.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 14 parameters, no output schema, and no annotations. The description provides almost no context about the operation's purpose, the role of each parameter group, or the expected response, making it completely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (every parameter has a GraphQL type note), so baseline is 3. The description lists all variable names and provides an example JSON, but it does not clarify the semantics of parameters such as the required 'user' field or what the pagination-like filters (after, filter, first, order) control.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name ('mutation resetMfa') and labels it as user-related, but does not explain what resetting MFA entails. It lacks a specific verb phrase like 'Resets the multi-factor authentication configuration for the specified user,' making it a tautology of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools like update_user or generate_password_link exist, but the description does not distinguish this operation or provide context for when resetting MFA is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 fails to mention side effects, required permissions, return values, or any consequences of the mutation. The description only lists parameters and an example, providing no transparency about what the tool does beyond being a GraphQL mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense technical dump with a long, truncated example. It is not concise, and the example takes up space without providing complete insight. The structure is list-like but fails to convey the tool's purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 1 required, no output schema, and no annotations, this tool needs a thorough description to be usable. The current description only lists parameter names and an incomplete example, leaving the agent without any understanding of what the mutation does, what the input object requires, or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists all parameter names and provides an example, but the example is truncated and uses placeholders without explaining field meanings. It adds minimal value beyond the schema's type-only descriptions, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the operation name as 'mutation updateRole' and adds the context 'Access Groups', but does not explicitly state that it updates a role. It is essentially a tautology of the tool name, providing no specific verb+resource clarification beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_access_group or update_pod. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists variable names and an example. It fails to state the mutation's effect, required permissions, or any side effects, making it non-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a flat, unstructured dump of variable names and a truncated JSON example. It lacks a clear introductory sentence and is not front-loaded with the most useful information, appearing under-specified rather than concisely complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 14-parameter mutation with no annotations and no output schema, this description is severely inadequate. It provides no context on return values, side effects, or required fields, leaving the agent with only a partial example and a list of parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% per context, so the schema already documents each parameter. The description adds only a raw list and an example with placeholders like '<ID HERE>', but it does not clarify meanings beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'User · mutation updateUser' essentially restates the tool name and indicates it's a mutation, but provides no explicit statement of what the tool does. It does not distinguish this from sibling update tools like update_pod or update_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool or how it relates to alternatives. The raw variable list and example offer no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only labels the tool as a 'mutation,' implying a write operation, but does not explain side effects, idempotency, whether it requires an existing record, what happens to omitted fields, or any permissions needed. The example variables show a structure but not behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but the leading phrase 'Playbooks · mutation upsertPlaybookMetadata' merely restates the tool name and wastes the front-loaded position. The example block is useful but not explained. It is not poorly sized, but the structure does not maximize the limited space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the operation is a mutation. The description fails to explain what the mutation does, what the response looks like, or any context such as required fields, validation rules, or relationships to other playbook entities. For an upsert operation, this is critically incomplete—an agent cannot understand the effects or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the schema's description for 'input' is merely a GraphQL type reference. The description adds value by providing an example of the input object's structure (id, name, description, enabled, type), which helps agents understand what fields to populate. The customer_slug parameter is well-described in the schema itself. Thus, the description compensates beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology of the tool name: 'Playbooks · mutation upsertPlaybookMetadata.' It does not clearly state that the tool creates or updates playbook metadata in plain language. The example variable block hints at the purpose (fields like name, description, enabled, type), but the description itself lacks a specific verb+resource statement, making it hard to distinguish from sibling tools like upsert_customer_playbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as playbooks, upsert_customer_playbook, or run_playbook. There are no conditions, prerequisites, or exclusions mentioned. The category 'Playbooks' is too vague to serve as a usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it only says 'query user.' It does not reveal read-only status, return format, pagination behavior, or the meaning of the numerous nested variables. The example structure hints at complexity but fails to explain side effects or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is concise, but the structure is poor: it leads with a two-word phrase then dumps a long truncated JSON example. This isn't well-organized, and the example is cut off, leaving incomplete information. It earns a mid score because it is short but not effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 14 parameters, no annotations, and no output schema. The description provides almost no context: no explanation of what the query returns, no guidance on the nested filter variables, no mention of pagination or any special behavior. It is greatly insufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters have at least type info), so baseline is 3. The tool description adds value by providing an example that shows the internal structure of 'filter' (with keys like customers, ids, name, pods, roles, users) and 'order' (direction, orderBy), which the schema does not explain. However, it doesn't explain each parameter's purpose, so only marginal added semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'User · query user.' which essentially restates the tool name and provides minimal information. It doesn't distinguish this singular 'user' query from siblings like 'users' (plural), 'me', or 'create_user'. The verb+resource is present but vague and nearly tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a user ID, or any context where this should be preferred over 'users' or other user-related tools. The lack of any usage direction earns a 'no guidance' score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that discoverExposure is omitted as a workaround for a server-side error, which is a useful limitation. However, it provides no details about authentication, rate limits, response shape, or what 'query case' actually returns, leaving major behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a lengthy, unstructured dump of all parameter names, repeating what's in the schema. The example is truncated with '...', and the key note about discoverExposure is buried at the end. Important information is not front-loaded, and the verbosity adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 54 parameters, no output schema, and no annotations, this description is incomplete. It doesn't explain the meaning of the required 'by' parameter, the relationships among nested children/comments/groups/pods/roles, or what the query returns. The discoverExposure note hints at a known limitation but doesn't cover the overall data shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has at least a GraphQL type), so the baseline is 3. The description adds a partial example showing how to structure filter and order objects, which gives some semantic nuance beyond bare types. However, the long list of parameter names is redundant with the schema, and most nested filter/order pairs are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Cases · query case.' which is barely more than a restatement of the tool name. It doesn't clarify whether this retrieves a single case by ID, a list, or something else, and it fails to distinguish from the sibling 'cases' tool or update_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 mention of another tool is the note to use graphql_query for discoverExposure, but that's about a missing field, not general usage. No context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for disclosing behavior. It only labels the operation as a 'mutation', which implies modification, but does not describe permanence, side effects, authorization needs, or any consequences. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no unnecessary words. It follows a clear structure: domain, mutation name, variables, and example. However, it is under-specified, but for conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It lacks information about return values, error behavior, or the effect of deletion. For a mutation tool, this is incomplete and requires the agent to make assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so baseline is 3. The description does add a concrete example variable JSON, which aids invocation, but it does not elaborate on parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reference Lists · mutation deleteReferenceListRow' essentially restates the tool name in camelCase, adding only the domain category 'Reference Lists'. It does not explicitly say 'Deletes a row from a reference list', so it borders on tautology rather than a clear statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as delete_reference_list_column or update_reference_list_row. The description only mentions variables and an example, with no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral context. It doesn't disclose whether the operation is read-only, any rate limits, pagination, or output format, leaving the agent to infer everything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes an example, but it's structurally awkward ('Data · query timeBuckets. Variables: filter. Example variables: ...'). It's concise but lacks a clear, organized explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex filter and no output schema, yet the description provides no explanation of what the query returns or what time buckets represent. The example helps but is insufficient for an agent to understand the tool's full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for 'filter' are purely type-based ('GraphQL: TimeBucketsFilter!'), so the description's example JSON adds real value by revealing the structure: 'by', 'startTime', 'endTime', and 'query'. This gives concrete guidance for constructing the filter, even though field semantics aren't fully explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Data · query timeBuckets' which is vague and largely restates the tool name. It doesn't explain what a time bucket is, what the query returns, or how it differs from other query tools like 'graphql_query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The example filter includes an incidentId and time range, hinting at a possible use case, but no explicit conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely labels the mutation and lists variables, with no mention of side effects, permissions, whether it replaces existing data, or any other behavioral context. It is essentially a stub.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than effectively concise. It lacks an actual explanation of the tool's purpose and parameter roles, making it a cryptic fragment rather than a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description is incomplete. It does not explain the effect of updating call order, how id is used, or mention the optional customer_slug parameter. The description is insufficient for an agent to understand when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions, though they are minimal ('GraphQL: Int!'). The description adds an example variable mapping, which provides a small amount of practical guidance, but it does not clarify the semantics of callOrder or id beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides the domain ('Emergency Contacts') and the operation name ('mutation updateCallOrder'), but it essentially restates the tool name without explaining what the mutation does. It does not explicitly state that it updates the order of an emergency contact, nor does it distinguish itself from sibling tools like update_emergency_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus other emergency contact tools or similar update operations. There are no prerequisites, scenarios, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely labels the operation as a 'mutation' without explaining side effects, required permissions, return behavior, or error conditions. The example variables hint at structure but not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the mutation name, but it lacks a proper explanatory sentence. The example is useful but the overall structure feels like a stub rather than a well-crafted description. It is concise yet under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and only two parameters, this description is severely incomplete. It does not explain what the tool accomplishes, what the return value is, or any operational details. Users would need external documentation to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only says 'GraphQL: CreateReferenceListRowInput!', which is unhelpful. The description compensates by providing an example variable structure ('referenceList' and 'values' with 'column' and 'value'), adding meaningful semantics beyond the schema. However, it does not explain each field's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name as 'mutation createReferenceListRow' and gives a variable template, without explicitly stating that it creates a new row in a reference list. It lacks a clear verb+resource statement and does not distinguish it from sibling tools like update_reference_list_row or delete_reference_list_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools exist for related operations (update, delete, create reference list), but the description provides no context about appropriate use cases, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a mutation (implying a write), but doesn't disclose side effects, return values, required permissions, or reversibility, leaving significant gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a long, truncated example JSON that seems auto-generated and isn't useful without further explanation. The opening phrase is brief, but the overall structure is cluttered and not front-loaded with the most essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with 10 parameters and no output schema, this description is severely insufficient. It doesn't explain what a role is, how creation works, or what the parameters are for, making it impossible for an agent to understand the tool's context or use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds an example variable structure for filter and order, which provides some context beyond the schema's 'GraphQL: AccessGroupFilter' labels, but it doesn't explain the required 'input' parameter and is truncated, so extra meaning is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Access Groups · mutation createRole', which essentially restates the tool name (create_role vs createRole) without offering an explicit statement of what the tool does or which resource it mutates. It doesn't differentiate the tool from siblings like create_access_group or update_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It lists variables and an example but provides no context on prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It provides no information about return structure, side effects, authorization requirements, pagination behavior, or error conditions. The term 'query' implies a read operation, but that is minimal and not sufficient for a tool with this complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single line listing variables and a truncated JSON example. It avoids bloat but is under-specified for a 7-parameter tool. The front-loaded 'Detections · query customerDetection' is a minimal identifier, but the brevity sacrifices necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter query tool with no output schema and no annotations, the description is incomplete. It fails to describe what the tool returns, how pagination works, or how the filter should be structured beyond a partial example. It also omits any mention of the customer_slug override header that appears in the schema, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 7 parameters, but they are non-semantic GraphQL type labels. The description adds a partial example variables object that shows fields like 'activityLogType' and 'bulkJobId', giving some practical insight. However, the example is truncated and does not explain each parameter's purpose, so it adds only marginal value over the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Detections · query customerDetection,' which essentially restates the tool name without clarifying whether it fetches a single detection or lists them. It does not distinguish itself from sibling tools like 'customer_detections' or 'customer_detection_activity_log_entries'. The presence of required 'id' and 'by' parameters hints at a single-item query, but this is never explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It merely lists variables and a truncated example, with no mention of use cases, prerequisites, or exclusions. The agent is left to infer the intended usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavior such as pagination limits, header requirements (e.g., customer_slug), or side effects. The word 'query' implies a read operation, but no behavioral details are given, leaving the agent without critical safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but broken into a fragment 'Detections · query customerDetections.' followed by a long truncated JSON example. It is not front-loaded with a clear action sentence, and the abridged example reduces its usability and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, this complex query tool (nested filter, pagination) needs a robust description explaining return values and behavior. The description only offers variable names and a partial example, leaving the agent without enough information to correctly invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions merely restate GraphQL types ('String', 'Int'), which adds little value. The example variables in the description provide some concrete structure for the filter object, but it is truncated and leaves many fields unexplained, so it only partially compensates for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a GraphQL query 'customerDetections' and mentions variables like 'after' and 'first', implying a paginated list. However, it lacks a clear verb like 'list' or 'fetch' and does not explicitly state what the tool returns, making its purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as the singular 'customer_detection' sibling. The description only lists variable names and provides an example, with no context about when this query is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only labels the operation as a mutation and provides no information about side effects, irreversibility, permissions, or impacts on related data—critical gaps for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—a stub label plus an example. While it is not wordy, it is under-specified and lacks a proper explanatory structure, so conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no annotations and no output schema, the description should cover prerequisites, side effects, and error behavior. It provides only a label and example, leaving the tool under-documented and not clarifying its relationship to the 'assets' tool or other delete siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the schema's input description is a type-only reference ('GraphQL: DeleteAssetInput!'). The example variables ('assetId' and 'comment') add concrete structural meaning and help an agent construct a valid input, though field semantics are not fully elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reuses the tool name ('mutation deleteAsset') and adds no verb+resource explanation beyond the name. It provides no explicit statement of what deleting an asset entails or how it differs from sibling delete tools like delete_access_group or delete_pod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The example variables indicate an assetId and comment are expected, but there is no mention of prerequisites, conditions, or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely labels the operation as a 'mutation' but does not disclose that it permanently deletes a user, any required permissions, irreversibility, or impact on related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (one line), but it is under-specified rather than appropriately concise. It omits essential information that could be included without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete mutation with no annotations and no output schema, the description fails to provide critical context about side effects, when to use this tool over similar user-management tools, or the meaning of 'delete' in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the schema already documents the required 'user' and optional 'customer_slug'. The example variables in the description add minimal value beyond the schema, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'User · mutation deleteUser', which restates the tool name ('delete_user' → 'deleteUser') without explicitly stating what the tool does. There is no verb phrase like 'Deletes a user' to clarify the operation's effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives such as disable_user or enable_user. It does not mention prerequisites, conditions, or any decision context for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors such as read-only nature, pagination semantics, auth requirements, and what data is returned. The description provides none of this; it only names variables and gives an opaque example. The 'after' and 'first' parameters suggest pagination but the description never says so explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the core action ('query drpAlert'), followed by variables and an example. Every line is compact, but the terseness sacrifices necessary detail, making it more under-specified than truly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no explanation of return values, pagination behavior, or how the variables interact. The example shows 'after' and 'first' like typical GraphQL pagination, but the purpose of 'after1' and 'first1' is unclear. Given the rich set of sibling tools, this description is insufficient for an agent to understand what the tool does or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage but the descriptions are unhelpful (e.g., 'GraphQL: String'). The description at least lists the variables and shows an example with plausible values, offering some context for after/first as pagination cursors and by as a filter object. However, it omits customer_slug and doesn't explain parameter semantics beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it queries drpAlert (the GraphQL query name), but it doesn't explain what this returns or how it differs from sibling tools like drp_alerts or other alert operations. It's a step above a tautology because it identifies the underlying query, but lacks any functional scope or result description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 drp_alerts or other alert-related siblings. No mention of prerequisites, typical use cases, or exclusions. The description only provides variable names and an example, leaving the agent to guess its place among many alert tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'mutation' which implies a write, but does not explain side effects (e.g., whether it sends an email), required permissions, idempotency, or error conditions. The long list of unrelated-looking parameters (filter, order, etc.) adds confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dump of variable names followed by a long, truncated example JSON. It is not concise or structured; much of the content is redundant with the schema and lacks a clear explanatory lead. It does not front-load the purpose and instead buries the reader in parameter listings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with 14 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain the tool's purpose, return value, side effects, or why there are multiple filter/order/after parameters seemingly unrelated to 'forgot password.' The example is truncated and does not serve as functional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a list of variable names and an example JSON, which gives some structural hints (e.g., filter includes customers, ids, name, pods, roles, users). However, it does not explain the meaning of individual parameters in the context of send_forgot_password, and the schema descriptions are only GraphQL type names (e.g., 'GraphQL: AccessGroupFilter'). The example is also truncated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely states 'User · mutation sendForgotPassword,' which is essentially a restatement of the tool name and operation type, not a description of what the tool does. There is no clear verb indicating the action (e.g., 'send a password reset email') or explanation of the resource affected. It does not distinguish from sibling tools like generate_password_link or resend_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as generate_password_link or resend_invite. It only lists variables and an example, which does not convey appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but discloses nothing about side effects, permissions, or what the mutation actually does. It only labels itself as a mutation, which is already implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it sacrifices substance for brevity. The example variable section is useful, but the overall structure is more of a code comment than a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no output schema, the description should clarify what the tool does and what the required input represents. It only provides an example without explaining what the comment is attached to or how the customer_slug header factors in. It is minimally informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the schema only describes 'input' as 'GraphQL: DrpAlertCommentInput!' without exposing inner fields. The description's example variables reveal the expected structure (comment, drpAlertBy.id, shortCode), adding meaningful semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose (adding a comment to a DRP alert). It only says 'mutation addDrpAlertComment' which is a restatement of the name, and shows example variables. The example hints at the functionality but lacks a clear verb+resource description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like bulk_add_drp_alert_comment, update_drp_alert_comment, or delete_drp_alert_comment. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and behavioral traits but does not. It identifies the operation as a 'mutation' and shows an example input, but never explains what happens to matched alerts, whether the change is reversible, required permissions, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured: it begins with a label, then 'Variables: input', and then a long, cut-off JSON example. It wastes space on an incomplete snippet instead of offering a concise, front-loaded purpose statement, making it neither efficient nor clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a bulk mutation with a complex nested input (bulkCommentBy filter), no output schema, and no annotations. The description only provides a truncated example and lacks clarification of the filter criteria, comment content, or expected outcomes, making it inadequate for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions, giving high coverage, so the baseline is 3. The description adds a truncated example of the nested 'input' structure, which provides some insight into expected fields, but it does not explain the meaning of the fields or the customer_slug parameter beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name and type ('DRP Alerts · mutation bulkAddDrpAlertComment') without stating what the tool actually does. It does not explicitly say 'adds a comment to multiple DRP alerts' or describe the operation, and only the 'bulk' prefix distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like add_drp_alert_comment or update_drp_alert_comment. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It labels the operation a 'mutation,' indicating a write, but does not disclose side effects, required permissions, or the impact on incident status. The example shows 'state: RESOLVED' but does not explain the behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the mutation name, but it is under-specified. The example is useful, yet the overall structure feels like a code comment rather than a complete tool description. No unnecessary sentences, but more substance is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation with nested input and an output schema absent. The description does not explain the return value, required nested fields, or relationship to sibling incident tools. Given the complexity and many sibling tools, the description is inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents top-level parameters with 'input' as a GraphQL type, providing no nested structure. The example variables add value by illustrating the inner fields (aiChatId, closeCode, closeNote, incidentIds, state), giving the agent a concrete template beyond schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Incidents · mutation bulkCloseIncidents' largely restates the tool name without using a clear verb like 'Bulk-close incidents.' The example variables hint at the operation but do not explicitly state what the mutation does. It does not distinguish from the sibling 'close_incident' tool beyond the word 'bulk' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'close_incident' or 'update_incident_state'. The description does not mention prerequisites, exclusions, or context for using this bulk operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it reveals no side effects, permissions, irreversibility, or success criteria. It only provides a template for input variables, leaving the actual behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it borders on under-specification. It includes a useful example, yet the core label ('Cases · mutation cancelCase') adds little substantive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about the case lifecycle, required permissions, how cancellation differs from closing, or any consequences, making it insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is high, the schema's 'input' description is opaque ('GraphQL: CancelCaseInput!'). The example variables clarify the expected structure (caseId, closeCode, reason), adding practical meaning beyond the schema's sparse parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name ('mutation cancelCase') without explaining what canceling a case does. The example variables hint at inputs but do not define the operation's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or how it differs from sibling tools like close_case or update_case. Usage is only implied by the name 'cancelCase'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does state that the operation is a 'query' (implying read-only), and the example shows pagination-related variables (after, first) which hints at cursor-based fetching. However, it doesn't disclose required permissions, how the response is shaped, potential side effects, or rate limits. The coverage is minimal and mostly implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus an example), but the structure is a bit scatter-shot: it starts with 'Detections · query ...', then lists variables, then provides an example. The variable list is redundant with the schema, and the example is helpful but not integrated into a coherent explanation. It earns a pass for brevity but not for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, so the description must compensate by explaining what the tool returns and how to use all parameters. It only partially does so: the example covers most but not all parameters (customer_slug is omitted), and there is no description of the return value or expected response structure. The 'Detections' prefix gives a hint of domain context, but overall it's incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 goes beyond the schema by providing a concrete example that clarifies the meaning of 'after' as a cursor, 'filter' with types and user, and 'order' with direction and orderBy. This adds semantic value, though not all parameters (e.g., customer_slug) are explained in the example or narrative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'query customerDetectionActivityLogEntry' which essentially restates the tool name, adding only the verb 'query'. It doesn't explain what an activity log entry is, what it returns, or how it differs from the sibling tool customer_detection_activity_log_entries (plural). This is borderline tautological and lacks clear purpose beyond 'perform a query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like customer_detection_activity_log_entries or customer_detection. No context about use cases, prerequisites, or typical scenarios is provided, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. It does not state whether this is a read-only query, any side effects, pagination behavior, authentication requirements, or how results are returned. The example variables show filter/order but no explanation of their effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but the example is a dense JSON blob with placeholders. It front-loads the purpose but the example dominates the text and is not optimally structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description only provides an example payload. It doesn't explain the query's purpose, return shape, or context relative to other tools, making it insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The example variables clarify the structure of nested 'filter' and 'order' objects, which the schema leaves as generic {}. This adds meaning beyond the schema's bare 'GraphQL: ...' descriptions. However, it omits the 'customer_slug' parameter and doesn't explain each variable's purpose, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'User · query me' hints at querying the current user, but never explicitly states what the tool does or returns. The variables and example imply a filterable list query rather than a single entity, creating ambiguity. It does not differentiate from sibling tools like 'user' or 'users'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'user' or 'users'. The only hint is 'query me' implying current-user scope, but there are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as side effects, permissions, idempotency, or what happens to alerts being unwatched. The word 'mutation' is a type label, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but includes a long, truncated JSON example. It reads as a metadata dump rather than a coherent sentence, and the abrupt cutoff reduces clarity. It is not well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no annotations and no output schema, the description is severely incomplete. It fails to explain the bulk nature of the operation or how it differs from the singular un_watch_drp_alert tool, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal (e.g., 'GraphQL: DRPAlertBulkUnwatchInput!'), but the description includes example variables that demonstrate the input structure, adding concrete value. Although truncated, the example helps the agent understand nested fields like filter and assignees.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the operation name ('mutation unWatchDRPAlerts') without stating the tool's function in plain language. It does not clearly say it unwatches DRP alerts, and the verb is only implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like un_watch_drp_alert (singular) or watch_drp_alerts. The description lacks any context, exclusions, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the operation as a 'mutation' but provides no details about side effects, reversibility, required permissions, or impact on existing policies. With no annotations, the description carries the full burden, and it fails to disclose any behavioral traits beyond the implied write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense, unstructured run-on that mixes a label, variable list, and truncated JSON example in a single block. It is not concise or front-loaded; the useful example is cut off mid-value, and there is no clear organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no output schema, and no annotations, yet the description provides only a partial example and no explanation of return values, behavior, or parameter semantics. This is insufficient for an agent to select and invoke the tool correctly, especially given the complex input structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the schema descriptions are minimal (e.g., 'GraphQL: String'). The description adds a raw list of variable names and a truncated example that shows the structure of 'input' (accessControlPolicyIds, accessGroups with add/addAll/remove). This provides some semantic context, but it does not explain the meaning of each parameter or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('DRP Access Control · mutation updateAccessControlPolicies') without explaining what the mutation does to access control policies. It lists variables and an example but never states a clear verb+resource purpose, so it fails to distinguish from sibling tools like update_access_control_policy or create_access_control_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions. The example variables hint at usage but do not explain scenarios or trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states it is a 'mutation' (which the name implies) and shows an example with add/remove/replace operations, but does not explain consequences, required permissions, idempotency, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief but unstructured dump of variable names and a truncated JSON example. It lacks a front-loaded purpose statement, and the cut-off example suggests incompleteness, making it hard to parse and use effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, none of which are explained in context, and no output schema or annotations, the description is inadequate. It does not explain how the pagination-like parameters relate to the mutation, what the mutation does, or what the response contains. The example is truncated, compounding the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 a concrete example structure for 'input' (with accessGroups add/remove/replace), which is helpful for constructing the parameter. However, it does not clarify the meaning or purpose of the cursor/pagination variables (after, first, notFilter, order, etc.) or their dual sets, so value over schema is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'DRP Access Control · mutation updateAccessControlPolicy', which merely restates the tool name and labels it as a mutation. It never explicitly says 'Updates an access control policy' or describes the operation's effect. The example input hints at modifying access groups but does not clarify the overall purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like update_access_control_policies, create_access_control_policy, or delete_access_control_policy. The description only lists variables and an example, offering no contextual or comparative usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral effects. While 'mutation' implies a write, it doesn't state what changes occur, whether it's reversible, or any prerequisites. The example includes unrelated query variables (after, filter, first, order), which adds confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph dominated by a large JSON example, much of which is irrelevant to the mutation. It lacks a clear, front-loaded statement of purpose; under-specification and clutter reduce readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This mutation tool has no annotations, no output schema, and an incomplete description. It does not explain return values, side effects, or the meaning of 'retained'. The example is the only clue, making the description inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's 'input' parameter is only described as a GraphQL type name, so the description compensates by showing the input structure with 'retained' and 'taskId' fields. However, the inclusion of extraneous query variables may mislead an agent about which parameters belong to the mutation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as 'mutation updateTaskRetainedStatus' and provides an example variable object, but never explicitly states that it updates a task's retained status. The example input with 'retained' and 'taskId' hints at it, but it's not an actionable definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or how it differs from sibling tools like update_task_state or retain_incident. The description lacks any context for when this mutation should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only signals 'query', which hints at a read-only operation, but it does not state read-only behavior, pagination, authorization requirements, or any side effects. The truncated example variable block adds no explicit transparency about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short, but it includes a truncated raw JSON example that is not clearly formatted and cuts off mid-string. It front-loads the operation name and variable list, but the abrupt example makes it feel unstructured and less polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 6-parameter query with no output schema, and the description does not explain what data is returned, how filtering works, or the meaning of 'by'. The example is truncated and incomplete. Given the complexity and missing schema information, the description is insufficient for an agent to confidently select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameter names and GraphQL types. The description adds an example filter object with fields like activityLogType, bulkJobId, and draftCustomerDetectionId, which gives some insight into the expected shape. However, it does not explain the meaning or purpose of each parameter, and the required 'by' parameter remains opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: 'query draftCustomerDetection'. It adds 'Detections ·' as a category but does not say in plain language what this query returns or what action it performs. It is not a specific verb like 'list' or 'retrieve', and it does not meaningfully distinguish from sibling detection tools beyond the 'draft' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusion criteria. The description only lists variables and an example payload, which implies usage mechanics but does not explain the intended use case or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 little beyond the input example showing discoverTaskId and state='CLOSED'. It does not mention side effects, permissions, reversibility, or exact behavior—making it hard for an agent to anticipate consequences of invoking the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes a useful example payload, so it does not waste words. However, it is under-specified: the label-like phrasing and minimal explanatory text mean the conciseness is more a result of lack of content than thoughtful prioritization. It is not as clear or efficient as a well-crafted one-sentence description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input object, lack of output schema, and absence of annotations, the description is insufficient. It provides an example template but omits valid state values, the mutation's effect, and how it differs from sibling tools. An agent cannot confidently select this tool or construct a correct invocation beyond copying the example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic 'input' object with a type reference, so the example in the description adds meaning by revealing the fields discoverTaskId and state. It provides one example value for state but does not enumerate all possible states or explain the semantics of each field. This adds some value beyond the schema, but not comprehensive coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Discover Tasks · mutation updateDiscoverTaskState' but does not clearly explain what the mutation does. It mostly restates the tool name and provides a GraphQL label, offering no specific verb or outcome beyond the vague 'update state.' The example hints at setting state to CLOSED but the purpose remains implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like close_discover_task, assign_discover_task, or update_task_state. There are no usage conditions, exclusions, or alternative recommendations, leaving the agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only labels the operation as a 'mutation' and gives an example payload, without mentioning side effects, partial vs. full updates, required permissions, or error handling. This is far below what an agent needs to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the mutation identity, followed by a useful example. There is no redundant prose, and the example earns its place by compensating for the schema's lack of detail. It is not perfectly structured, but it is appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 and annotations, the description does not explain the return value, behavior on invalid IDs, or update semantics. The example input provides some context, but the tool remains under-specified for an agent to invoke it confidently in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's 'input' parameter description is just 'GraphQL: UpdateEmergencyContactInput!' which gives no structure. The example variables in the description compensate by showing the nested fields (callAttempts, callCategories, callWindows, id, phoneNumber) and their types. This adds meaningful shape beyond the schema, though it doesn't explain field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mostly restates the operation name ('updateEmergencyContact') and the resource ('Emergency Contacts'), making it a tautology. It does not explain what updating an emergency contact accomplishes, though the example variables hint at modifiable fields. This is insufficient to distinguish the tool from its create/delete siblings beyond the verb in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_emergency_contact or delete_emergency_contact. It does not state prerequisites (e.g., an existing contact ID) or provide exclusions. The user must infer usage solely from the name and example input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It only labels the operation as a 'mutation' and lists variables; it does not disclose side effects, reversibility, permissions, response format, or what exactly gets modified. The truncated example hints at filtering and ordering but stops mid-string.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably short and front-loads the domain with 'Reference Lists · mutation updateReferenceList,' but the variable list redundantly repeats schema property names, and the example JSON is truncated mid-value. The structure is a bare GraphQL summary rather than a purpose-built, organized explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation with seven parameters, nested input objects, no output schema, and no annotations, the description is inadequate. It provides an incomplete example and no behavioral detail, leaving the agent without essential context for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is reported at 100%, but the property descriptions are minimal type labels like 'GraphQL: String' and 'GraphQL: UpdateReferenceListInput!'. The description's example JSON adds some structural context for nested parameters such as columnSelector, filter, and order, which is useful, but it omits customer_slug and is cut off, so it only partially compensates for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reference Lists · mutation updateReferenceList,' which is essentially a restatement of the tool name and operation type. It does not clearly state what the mutation does or how it differs from siblings like update_reference_list_row and update_reference_list_column, and the remainder is a variable list plus truncated example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as create_reference_list, update_reference_list_row, or update_reference_list_column. The description provides only variable names and an example, with no contextual guidance, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 operation is a 'mutation', indicating a write operation, but does not disclose effects such as state changes, permissions required, or reversible behavior. The example shows input fields but not what happens when the mutation is executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact, but it is not front-loaded with a clear purpose. The variable list repeats schema information, while the long JSON example is useful but not structured into an easy-to-parse explanation. It is terse yet lacks the initial clarity needed for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is incomplete. It fails to explain what acknowledging a task does, when to use it, or what response to expect. The example JSON provides some context, but the overall behavior and selection criteria are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% for top-level parameters, the 'input' parameter is opaque in the schema (only 'GraphQL: AcknowledgeTaskInput!'). The description's example variables provide concrete insight into the expected structure, including actionMethod and taskId, which adds meaningful value beyond the schema. However, the listed variables at the start are redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Tasks · mutation acknowledgeTask', which essentially restates the tool name and GraphQL operation type without explaining what acknowledging a task does. It provides no specific verb+resource description beyond the name, and does not differentiate from sibling tools like resolve_task or assign_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description only lists variables and an example, with no mention of prerequisites, context, or exclusions. A knowledgeable agent would have to infer from the name 'acknowledgeTask' that it is used to acknowledge a task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only says 'query' without detailing return format, pagination behavior, rate limits, or whether the operation is read-only in a meaningful way. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-liner but then includes a long, truncated example variable block that is difficult to parse and not well-structured. It is not concise or well-organized for quick agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex query tool with a GraphQL filter object, no output schema, and no annotations. The description provides almost no context on return values, pagination, filter usage, or expected behavior, making it inadequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameter names and types, so baseline is 3. The description adds an example variables block showing the nested filter structure, which provides some semantic context beyond bare types, but it is truncated and does not explain each parameter in depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'query assets', identifying the specific verb and resource. It distinguishes itself from mutation tools like delete_asset, though it doesn't differentiate from sibling query tools like cases or incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, exclusions, or comparisons to sibling query tools, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only reveals that this is a mutation and lists variable names/example values, but says nothing about effects, permissions, idempotency, or what happens when a task is created. This is essentially a schema echo with no behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the operation type, but the variable list and truncated example are not well-explained. It earns its place minimally but lacks meaningful structure or explanatory context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must provide return values, effects, and usage context. It provides none. For a mutation with six parameters and numerous sibling tools, this is critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 example variables that illustrate usage of filter, order, and input, which slightly helps. However, it does not explain the purpose or format of each variable beyond the schema's bare GraphQL type references.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'mutation createTask' with a clear verb+resource, indicating it creates a task. However, it does not differentiate from many other task-related or create_* sibling tools, and it provides no context on what a task is in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like create_case, create_user, or discover_task. It lacks any mention of prerequisites, scenarios, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only repeats 'mutation deleteReferenceListColumn' and lists a variable, adding no information about side effects, irreversibility, permissions, or what happens to associated data. This is a tautology of the tool name with no added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the structure is a jumble: 'Reference Lists · mutation deleteReferenceListColumn. Variables: id. Example variables: ...' It reads like auto-generated metadata, not a human-written explanation. The sentence about variables repeats the schema. The content is minimal, but the lack of organization and substance makes it less than useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a delete mutation with no output schema and simple parameters, but the description still fails to adequately explain the operation. It doesn't specify what a reference list column is, what the id refers to, or any consequences of deletion. Given the presence of related sibling tools, more context is needed to avoid confusion. The description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters, so the baseline is 3. The description adds an example for 'id' and mentions it, but omits the optional customer_slug parameter. The example placeholder is trivial and doesn't deepen understanding beyond the schema, but since the schema already documents both parameters, the description meets the baseline without adding much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the operation as 'deleteReferenceListColumn' and labels it a mutation, clearly indicating a delete action on a reference list column. The verb and resource are specific, and the tool name itself disambiguates from sibling tools like delete_reference_list or delete_reference_list_row. However, it doesn't provide an explicit statement of what a reference list column is, but the name suffices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or contrasts with sibling delete operations. Only an example variable is provided, which is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. 'query' implies a read operation, but the description does not disclose pagination behavior (despite after/first variables), ordering semantics, or the structure of the response. It also does not state whether any side effects or special permissions are involved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but poorly structured: it starts with a cryptic 'Playbooks ·' prefix, then lists variables, then an example that cuts off mid-value ('ticketNum...'). This truncation reduces effectiveness and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain return format and usage more thoroughly. It does not state what the tool returns, how pagination works, or what the filter fields represent beyond the example. For a query tool with a complex nested filter, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type-level descriptions (e.g., 'GraphQL: PlaybookRunFilter'), and the description partially compensates by listing the variables and providing an example filter object with fields like created, platforms, and statuses. However, not all parameters are semantically explained (orderBy, customer_slug), and the example is truncated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Playbooks · query playbookRuns' identifies the resource as playbookRuns and indicates a query operation, but it lacks a strong action verb like 'list' or 'fetch' and does not distinguish from sibling tools such as playbook_run or playbooks. The inclusion of variables hints at read behavior but the purpose is not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It merely lists variables and an example filter, without stating use cases, prerequisites, or exclusions. The agent is left to infer that this queries playbook runs, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states 'mutation' and gives a variable example. It does not mention side effects, required permissions, reversibility, or what happens on success/failure, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is fragmented and not composed as a coherent sentence. The example variables are useful, but the overall structure is more of a schema-generated snippet than a well-organized explanation, with some redundancy ('Variables: input' repeats schema info).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This mutation tool has no annotations and no output schema, so the description needs to explain what the tool does, when to use it, and what to expect. Instead, it offers only a technical mutation name and an example input, leaving major gaps in purpose, side effects, and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal ('GraphQL: UpdateReferenceListRowInput!'), but the example in the description ('input: {id, values: {column, value}}') adds meaningful structure beyond the schema, clarifying the nested shape of the required input parameter. The customer_slug parameter is clearly described in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the mutation name ('mutation updateReferenceListRow') and provides a domain prefix ('Reference Lists') without explicitly stating what the tool does. The example variables hint at updating a row's column value, but no clear verb+resource statement is present, making it nearly tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as update_reference_list_column or update_reference_list_row variations. It only provides an example, so an agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only labels the operation as a mutation, implying a write, but does not describe what changes are made, required permissions, side effects, or reversibility. This leaves the agent guessing about the impact of calling the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, essentially one line with an example. It is concise, but the phrasing is cryptic and lacks clear sentence structure. It front-loads 'Discover Tasks' rather than a clear action verb, making it less easily parseable. The example adds some value but the overall structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is severely lacking. It does not explain the full structure of the input object, the effects of the mutation, prerequisites, or the response format. The example is the only useful part, but it is insufficient for safe invocation and does not cover required inputs comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's description for 'input' is merely 'GraphQL: AssignDiscoverTaskInput!', which provides no field details. The description's example variables show that input contains assignee and discoverTaskId, adding some semantic meaning. However, it does not explain types, other required fields, or the customer_slug parameter, which has a clear schema description but is absent from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'mutation assignDiscoverTask' and mentions 'Discover Tasks', but does not explicitly say 'assign a Discover Task to an assignee'. The example variables hint at the operation, but the description lacks a clear verb+resource statement. It is somewhat vague but distinguishable from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like assign_task, close_discover_task, or update_discover_task_state. No conditions, exclusions, or alternative references are provided. The example simply shows variable names without explaining appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only labels the operation as a 'mutation' and gives an example input payload. It does not state side effects, overwrite behavior, permission requirements, or what happens to existing assignments or comments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the operation name and resource. The example variables are helpful, though the 'Variables: input' phrase is boilerplate. Overall, it is compact and logically structured, but the brevity comes at the cost of explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no output schema and no annotations, the description should explain what assigning a DRP alert entails, what 'shortCode' means, whether comment is required, and what the response contains. The example variables partially compensate, but the description remains incomplete for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers top-level parameters, the input object is only described as 'GraphQL: DRPAlertAssignmentInput!', which is meaningless without nested field definitions. The example variables add concrete field names and placeholder values (assignee, comment, shortCode), providing the most useful semantic detail for constructing a valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'DRP Alerts · mutation assignDRPAlert', which largely restates the tool name and does not provide a plain-language statement of what the tool does. The example variables hint at assigning via an 'assignee' field, but the purpose remains implicit and does not clearly differentiate from the sibling 'assign_drp_alerts' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as unassign_drp_alert, watch_drp_alert, or update_drp_alert_state. The description does not mention prerequisites, whether it handles single vs. bulk assignment, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it's a 'mutation,' implying a write operation, but discloses no details about required permissions, side effects, return values, or error behavior. The example variables are not behavioral explanations, so the transparency is essentially nil.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but structurally fragmented: 'API Keys · mutation createApiKey' is a label rather than a coherent sentence, and 'Variables: input' is redundant with the schema. The example is useful but could be integrated more naturally. It earns a mid score because it is concise but not well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested input object and no output schema, yet the description does not explain required fields, the return value, or what happens upon creation. The example helps but leaves significant gaps. For a mutation of this complexity, the description is incomplete and would likely leave an agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's 'input' parameter is merely described as 'GraphQL: CreateApiKeyInput!' with no internal fields exposed. The description's example reveals that the input object accepts 'expiryTime' and 'user,' adding crucial shape information beyond the schema. Although schema coverage is 100%, the input description is a type reference, so the example meaningfully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as 'mutation createApiKey' within 'API Keys,' making it clear this creates an API key. While it doesn't use a full sentence, the verb 'create' and resource 'API key' are explicit, and the example variables reinforce the purpose. The name itself distinguishes it from sibling list/delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like api_keys (list) or delete_api_key_by_id. There are no prerequisites, exclusions, or context about when this mutation is appropriate. The example variables are the only hint, but they don't address tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the full burden of behavioral disclosure. While 'query' implies a read operation, the description does not confirm safety, nor does it explain the dual pagination variables (after/first and after1/first1) or the return format. This leaves significant behavioral assumptions unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and not overly verbose, but its structure is poor: the leading 'Customer ·' is redundant, and the variable listing plus example is presented without clear organization. It is not concise in the sense of being well-structured, but it is short enough to merit a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description must explain the return value, pagination semantics, and parameter roles. It fails to state whether this returns a single customer or a list, the meaning of the two pagination pairs, or the role of customer_slug. This is a significant gap for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, but the field descriptions are redundant ('GraphQL: String'). The description adds an example with actual cursor and count values, which provides minimal syntax guidance, but it omits customer_slug and does not explain the purpose of the second pagination set. It adds marginal value, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'query customer', which is a clear verb+resource, but it does not specify what the query returns (single customer vs list), how it is filtered, or how it differs from sibling tools like 'customers'. This ambiguity weakens its purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided for when to use this tool over alternatives. The description only lists variables and an example, without any context about appropriate use cases or exclusions, making it hard for an agent to decide between this and similar query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'query', implying read-only, but does not disclose pagination behavior, return format, or any side effects. The example variables hint at filter structure but add no explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with no fluff, but it is underspecified. The example variables are truncated, and the entire description fits in two short lines, which is concise but lacks substance. It is not front-loaded with the most critical information because there is almost nothing beyond the bare function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with six parameters, no output schema, and no annotations, the description is inadequate. It does not explain the return shape, how filtering works, or relationship to sibling tools like 'customer'. The complexity of the query operation is largely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage but only with GraphQL type descriptors. The description lists variable names and provides an example filter object, which adds some semantic meaning by showing the expected structure (e.g., accessGroups, roles, users). However, it does not explain individual parameters or their effects in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'query customers', which provides a verb and resource, but it's vague and essentially restates the tool name. It doesn't specify whether this returns a list, supports filtering, or distinguishes from the singular 'customer' sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'customer' (singular). There is no mention of use cases or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a query operation but does not disclose side effects, authentication needs, rate limits, or behavior on missing fields. The word 'query' suggests read-only but provides no explicit safety assurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the operation. It wastes no words and includes a useful example. However, it is under-specified, which limits its value despite good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should at least indicate the return value or type. It does not. The description also fails to clarify how this singular tool relates to the plural greymatter_fields sibling, leaving the agent without enough context to choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are cryptic ('GraphQL: GreyMatterFieldBy!'). The example variables {'by':{'id':'<ID HERE>','name':''}} clarify that 'by' is an object with id and name fields, adding meaning beyond the schema. Since schema coverage is 100% and the example enriches the semantics, a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'query greymatterField' but does not state what a greymatterField is or what the tool returns. It is more of a template than an explicit purpose statement, and it does not distinguish from the sibling tool 'greymatter_fields'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like greymatter_fields. The description lacks any contextual cues about use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a read via 'query' but does not explain pagination, authorization requirements, return format, or side effects. The variable list provides no behavioral context beyond field names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact line with a variable list and example; no wasted words. The technical format is efficient but lacks narrative context, making it slightly less readable yet still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 13-parameter query with no output schema and no annotations. The description omits return value details, domain context, and usage guidance, leaving significant gaps. The example JSON only partially compensates for these missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but descriptions are only GraphQL types, so the baseline is 3. The description adds an example JSON illustrating structure for filters, ordering, and cursor parameters, which is helpful, but it does not explain the semantic meaning of each parameter beyond identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'query accessControlPolicy', which identifies a read operation for a single policy, but does not state in plain language what the tool does or how it differs from siblings like access_control_policies. It is not tautological but remains vague about the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as access_control_policies (plural) or create/update/delete policy tools. The example shows how to construct a query but does not explain the appropriate use case or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not state whether the operation is destructive, what side effects occur, or what the response contains. Including query-like variables (after, filter, order, first) without explanation is misleading for a mutation tool, as it suggests filtering/ordering capabilities that are not relevant to adding a comment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a redundant list of variables already present in the schema and a long example JSON string. The example may be useful but is not well-integrated, making the description cluttered and lacking clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no annotations, and no output schema, the description is inadequate. It fails to clarify the role of the optional variables, explain expected behavior, or describe return values. The confusing inclusion of filter/order variables without explanation leaves an agent unable to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for all parameters, but they are generic type labels (e.g., 'GraphQL: String') that add little value. The description supplements this by specifying the input shape (IncidentCommentInput { incidentId, comment }) and providing a concrete example. However, it does not explain the meaning or purpose of after, filter, order, and first, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Add a comment to an incident,' which clearly identifies the action and target resource. It distinguishes this from sibling tools like add_case_comment and add_task_comment by naming the incident resource specifically. The additional input type mention reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as add_case_comment or add_task_comment. It does not mention prerequisites, permissions, or exclusions. The only usage indication is the purpose statement itself, which is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only marks the operation as a GraphQL mutation. It does not mention permissions, side effects, validation rules, owner value format, or what happens if the case or owner is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler; the example payload is placed efficiently. However, the prose is fragmented and the redundant 'mutation updateCaseOwner' phrasing consumes space that could have been used for a human-readable explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It fails to explain the accepted owner format, whether the update replaces or appends, and any related prerequisite steps, leaving substantial gaps for an agent attempting to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema describes both parameters, the 'input' parameter's schema is opaque ('GraphQL: UpdateCaseOwnerInput!'). The description adds value by showing an example input object with caseId and owner fields, giving the agent concrete syntax for invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the operation as 'mutation updateCaseOwner' plus an example payload, without explicitly stating that it changes the owner of a case. The example variables make the purpose inferable, but the prose does not provide a clear verb+resource description or distinguish it from related case-update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives like update_case, close_case, or assign_incident. The description provides no context, prerequisites, or exclusions, so the agent must rely on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states that it is a mutation and gives an example input, but does not describe side effects, permissions, or whether it replaces an existing comment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a labeled example, which is useful. There is no wordiness, but the brevity contributes to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks explanation of the operation's effect, when to use it, and how it differs from related comment tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is a type reference ('DrpAlertUpdateCommentInput!') and adds little meaning. The example variables ('comment' and 'drpAlertComment') provide useful semantic hints about the expected input structure, partially compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'mutation updateDrpAlertComment' which effectively restates the tool name. The example variables hint at updating a comment, but the description does not explicitly state that it updates a DRP alert comment. It is somewhat vague and does not differentiate from add/delete comment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like add_drp_alert_comment or delete_drp_alert_comment. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden for behavioral disclosure. It only says 'query accessGroups' and lists variables, which implies read-only behavior but does not disclose return format, pagination semantics, error behavior, or any side effects. The example variables hint at filtering and pagination but do not explain them, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured. It consists of a fragment 'Access Groups · query accessGroups' followed by a list of variable names and a truncated JSON example. The example is not complete and ends with 'or...', making it look unfinished. While it is not overly verbose, the lack of clean structure and incomplete example reduce its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with 6 optional parameters, nested filter objects, and no output schema, the description is incomplete. It does not explain return values, pagination behavior, filter semantics, or how the parameters interact. The provided example is not enough to guide correct usage, especially given the complexity of the filter/notFilter structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all parameters with minimal 'GraphQL: ...' text, but the description adds an example showing the structure of filter and notFilter objects with placeholder IDs, which provides some semantic meaning beyond the schema. However, the example is truncated and does not explain the meaning or allowed values for each parameter, so it only partially compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query accessGroups' with a clear verb and resource. It distinguishes from siblings such as access_group, create_access_group, update_access_group, and delete_access_group by indicating this is a query operation for the plural resource. However, it lacks explicit scope like 'list all' or filtering behavior beyond what the example implies, so it's clear but not fully elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention that this is for listing multiple access groups as opposed to fetching a single one with access_group, nor does it mention any preconditions or exclusions. The usage context is only implied by the verb 'query' and the plural resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It labels the operation as a mutation but does not disclose side effects, required permissions, state transitions, or the meaning of the fields in the example. It adds minimal behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes a concrete example, but it opens with a categorical label and a mutation name rather than a clear action statement. It is concise but lacks a front-loaded, human-readable explanation, making it less effective than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a composite mutation with no output schema, yet the description provides no explanation of the combined workflow, prerequisites, or expected behavior. It only offers an example template, leaving the agent to infer the tool's semantics from the name and variable names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'input' as a GraphQL type, giving no field-level detail. The example variable block is the primary source of parameter structure, listing fields like acknowledgementMethod, assigneeId, closeCode, closeNote, incidentId, state, and type. This adds significant meaning beyond the schema, though it does not explain each field's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the mutation name and gives an example, but does not explicitly state that it acknowledges, assigns, and closes an incident. The name itself is descriptive, but the description lacks a clear verb+resource statement, so the purpose is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 composite operation versus the individual sibling tools like acknowledge_incident, assign_incident, and close_incident. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and permissions. It only states the operation and input fields, but does not mention whether the assignment overwrites existing assignees, requires specific permissions, or what mutations occur. The inclusion of query-like variables (after, filter, first, order) without explanation adds confusion rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured. It mixes prose with code-like variable declarations and a long JSON example without clear separation. While it is not overly verbose, the structure is confusing and could lead to misinterpretation of required vs optional inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, so the description should explain return values, side effects, or error behavior. It provides none of these. The example variables help with input format, but the overall context is incomplete for an agent to reliably invoke the tool and understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but each parameter description is minimal (e.g., 'GraphQL: String'). The description adds value by explicitly listing the input fields (taskId, assigneeId) in AssignTaskInput and providing an example. However, the roles of after, filter, first, and order are not clarified for a mutation context, leaving their purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign a task to a GreyMatter user') with a specific verb and resource. It is distinguishable from sibling tools like 'unassign_drp_alert' or 'resolve_task' by the explicit mention of GreyMatter user and task. However, it does not explicitly contrast with other assign tools (e.g., assign_drp_alert, assign_incident), making it slightly less precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives. The description only provides the action and variable structure, but no context about prerequisites, suitability, or exclusion of other assignment tools. It does not say 'use this when you need to change task assignee' or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'query audits' and provides an example, but does not disclose side effects, permissions, rate limits, pagination behavior, or any other operational traits. This is a significant gap for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes an example that is useful for understanding the input structure. It is concise and front-loaded with the key purpose. The variable list could be considered slightly redundant with the schema, but the example earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is too thin. It does not explain what audits contain, what filtering options exist beyond the example, or what the response looks like. Similar mutation tools with comparable gaps scored 2, and this is on par.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, but the descriptions are generic (e.g., 'GraphQL: String'). The description's example variables add a bit of context about the expected structure (e.g., filter with objectId, order with direction and orderBy), which goes beyond the schema. However, it does not systematically explain each parameter, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries audits related to user activity, which is a specific verb+resource. However, it does not explicitly distinguish this tool from siblings; it relies on the resource name 'audits' which is not shared by other listed tools, so clarity is good but not perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention scenarios, exclusions, or alternatives. The example variables provide some usage hints but no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'mutation' (already implied by the name) and gives an example. There is no mention of side effects, reversibility, required permissions, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes a concrete example, earning its place. However, it is not front-loaded with a clear sentence about what the tool does; it reads more like a code snippet.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It lacks usage context, behavioral details, and any mention of return values, making it inadequate for an agent to fully understand the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the `input` parameter only as a GraphQL type, which is unhelpful. The description adds an example object with closeCode and discoverTaskId, giving some practical meaning. However, it does not explain valid values for closeCode or the structure of the input object beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the operation 'closeDiscoverTask' and shows example variables with a discoverTaskId, making it clear this tool closes a discover task. However, it does not explain what 'closing' entails or distinguish it from sibling tools like update_discover_task_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as assign_discover_task or update_discover_task_state. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It hints at read-only behavior through 'query' and pagination via 'after' and 'first', but it doesn't explicitly state that it's a read-only operation, discuss rate limits, or describe what the response contains. The description fails to disclose any behavioral traits beyond the obvious query nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not well-structured; it's a single template fragment with a cut-off JSON example. It front-loads the operation name but the value is limited by the abrupt truncation, making it less readable than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the query returns, but it doesn't. The tool has 5 parameters and nested objects, but the description only provides an incomplete variable example. It lacks behavioral context, return value details, and pagination semantics, making it insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value with a concrete example showing the nested structure of 'filter' (activityLogType, bulkJobId, customerDetectionId, etc.) and 'order', which goes beyond the bare 'GraphQL: *' type descriptions. The example is truncated but still helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query customerDetectionActivityLogEntries', which is a verb+resource, but it doesn't explain what an activity log entry is or what the query returns. It reads more like a code template than a functional description, and it doesn't distinguish from the singular sibling 'customer_detection_activity_log_entry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The example variables imply filtering by bulk job or detection ID, but there's no explicit context, prerequisites, or exclusions. It's a bare query template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only lists variables and an example, without stating that this is a read-only query, how pagination works, or what happens with the filter. The behavior is implied but never explicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a redundant 'Query Management ·' prefix and a variable list that largely duplicates the schema. The example JSON is valuable but verbose. It is not maximally concise, though the structure is clear: intro, variables, example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, an agent cannot determine what the tool returns. The description provides an example input but not the response shape, pagination details, or error behavior. For a complex query tool with five parameters, this is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are generic GraphQL types, but the example variables add significant meaning by showing the concrete structure for integrationFilter and integrationOrder. This goes beyond the sparse schema and helps an agent understand how to construct valid inputs. However, individual parameter purposes are not described in words.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'query integrations,' which identifies the resource but not a specific verb like 'list' or 'fetch.' It is essentially a restatement of the tool name with 'query' prefixed, providing only vague purpose. The example variables imply it returns integrations based on filters, but that is not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling 'integration' (singular) might be the single-item counterpart, but the description never mentions this distinction or any other usage context. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only lists variable names and an example. It discloses no behavioral traits such as return format, permissions, pagination behavior, or side effects. Since no annotations are provided, the description carries the full burden, and this is a major omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with 'Access Groups · query pods' and then provides an illustrative example. It is reasonably concise, though the example is long and truncated. Every sentence earns its place, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, annotations, or a description of return values, the tool is underspecified. The example gives some context for the filter input, but the overall behavior (what is returned, pagination, errors) is missing, making it inadequate for a 6-parameter query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a concrete example showing the nested filter structure (accessGroups, customers, ids, name, roles, users), which provides some semantics beyond the generic GraphQL type labels in the schema. However, it does not explain each parameter's purpose in depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query pods', a clear verb+resource combination, and 'Access Groups' indicates a filtering context. It distinguishes from the singular 'pod' tool and mutation siblings like create_pod/update_pod/delete_pod. However, it lacks explicit mention of list/pagination semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is given. The description does not say when to use this tool over the singular 'pod' or other query tools, nor does it mention exclusions or alternatives. The 'query' phrasing implies read-only, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only offers the word 'mutation' and the example. It does not describe effects, idempotency, permissions, or error behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, consisting of a category, operation type, and a useful example. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description lacks usage guidance and behavioral context. It does not differentiate from similar case-related mutations, making it incomplete for an agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description's example reveals the structure of the 'input' object (caseId and dueAt), which is not detailed in the schema. This adds practical meaning for constructing a correct request, though it does not address customer_slug.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's function; it labels it as 'Cases · mutation updateCaseDueDate' and provides an example input. The purpose is inferable from the name and variable names, but the description itself is vague and does not distinguish this from siblings like update_case or update_case_owner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. There is no mention of use cases, prerequisites, or exclusions. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only labels the operation as a 'mutation' and shows an example payload, but it does not disclose valid state values, whether the comment field is optional, authorization needs, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'mutation updateDrpAlertState' restates the tool name and 'Variables: input' duplicates schema information. The example variables are the only content that adds value, and the structure is a run-on set of fragments rather than clean front-loaded sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should explain more—such as valid state transitions, required inner fields, and side effects. The example provides a starting point but is insufficient for an agent to safely and correctly invoke this tool in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's description of 'input' is merely the opaque GraphQL type name 'UpdateDrpAlertStateInput!', so the example variables add genuine meaning by revealing the nested shape (comment, drpAlert, state). This gives an agent the concrete structure of the required input, though field semantics beyond the example values are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name as 'mutation updateDrpAlertState' without an explicit statement of what the tool does. The example variables showing 'state': 'IN_PROGRESS' and 'drpAlert': '<ID HERE>' implicitly reveal that this updates a DRP alert's state, but the lack of a direct purpose sentence keeps this at a vague level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings like bulk_update_drp_alert_state and assign_drp_alert suggest related operations, but the description offers no differentiation, exclusions, or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only mentions 'mutation' and shows closeCode/closeNote, but fails to state side effects, irreversibility, required permissions, or what happens to the tasks. The mutating nature is implicit but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and gets to the point quickly. However, the line 'Variables: input' is redundant with the schema, and the opening 'Tasks · mutation bulkResolveTasks' is somewhat tautological. Still, it is efficient and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no description of the return value, effects on tasks, or bulk-specific considerations. The example provides input shape but leaves the agent without information about what the mutation accomplishes beyond the name's implication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's description for 'input' is just 'GraphQL: BulkResolveTasksInput!', which is uninformative. The tool description's example variables JSON adds structure by showing closeCode, closeNote, and taskIds, providing the agent with concrete usage that the schema lacks. customer_slug is already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name as 'mutation bulkResolveTasks' and provides example variables, but it does not explicitly state 'Bulk resolve tasks' in plain language. The example with taskIds and closeCode implies the action, but the purpose remains vague without a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like resolve_task or bulk_close_incidents. The description only shows an example input, with no mention of contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'mutation closeCase' without explaining side effects, permissions, reversibility, or what happens to the case, offering no value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with 'Cases · mutation closeCase', then provides a useful example. It could be more structured, but every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no annotations and no output schema, the description is too sparse. It doesn't explain field semantics, required versus optional fields, the effect of closing, or the response format, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only 'input' as GraphQL: CloseCaseInput!, but the example expands on this by listing caseId, closeCode, and reason fields, adding practical meaning beyond the schema. This compensates well for the schema's opaqueness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action as 'mutation closeCase' and provides an example with caseId, making it clear this tool closes a case. It distinguishes from siblings like cancel_case, though it could be more explicit with plain language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like cancel_case or close_incident. The example variables imply usage for closing a case, but there is no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It only states 'mutation', implying a write operation, but does not disclose side effects, required permissions, idempotency, or what happens on duplicate creation. The example variables are parameter-focused and do not clarify behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single block of text with a header, mutation name, and a lengthy example. It is not exceptionally long, but the format is awkwardly crammed together and lacks separation between the purpose statement and example. The example is useful but could be presented more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an input object with nested fields, but the schema does not expose those fields. The example partially compensates, but the description does not explain required fields, error conditions, or the return value. No output schema exists, so the description should clarify what happens after creation, but it remains silent. This is incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters, covering 100% of them, but the input description is merely the GraphQL type name and the customer_slug description is a header override. The description adds an example of the input structure, which provides additional context about nested fields, though many fields are empty or placeholders. Overall, the example adds some value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly labels this as a mutation named 'createEmergencyContact', which clearly indicates the tool creates an emergency contact. The resource is specific, and it distinguishes from other tools by its unique operation name. However, it does not provide a plain-language explanation of what an emergency contact is or what creation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as update_emergency_contact or delete_emergency_contact. No prerequisites, valid scenarios, or exclusions are mentioned. The only context is the GraphQL mutation name, which does not inform usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It merely labels the operation as 'mutation deleteAccessGroup', but fails to disclose side effects, irreversibility, permission requirements, or what happens to associated data. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it functions more as a code template than a tool description. It earns some value by stating the mutation name and variables, but lacks structured prose that explains the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple deletion by ID, but the description is minimal and relies on the name for meaning. It does not state what the deletion does, any prerequisites, or the expected result. With no annotations or output schema, this is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds an example for 'id' but no additional meaning beyond the schema. It omits mention of 'customer_slug', though the schema covers it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as 'deleteAccessGroup' within 'Access Groups', specifying a deletion mutation. This is unambiguous and distinguishes it from sibling tools like create_access_group and update_access_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It only states the mutation name and variables, without explaining circumstances for deletion or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a specific limitation (omission of supportedTechnologies due to a server error) and points to graphql_query as a fallback. However, with no annotations and no output schema, it does not clarify return values, permissions, or whether this is a read-only operation beyond the verb 'query'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but includes the template artifact 'Example variables: {}' which adds noise. The note about supportedTechnologies is useful, but the opening 'Playbooks ·' is redundant with the tool name, and the structure could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is incomplete. It does not explain what a playbook is, the shape of the response, or the intended use case, leaving the agent with insufficient context to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, customer_slug, is already fully described in the input schema. The description adds no additional meaning or context for this parameter, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries playbooks, providing a clear verb and resource. However, it does not explicitly distinguish itself from sibling tools like 'customer_playbooks' or the broader 'playbook_runs', so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'customer_playbooks' or 'recommended_playbooks'. The note about the server-side error is a workaround, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'query roles' and lists variable names. It does not explain pagination behavior, return shape, filtering semantics, or any side effects (likely none). The example provides some shape but is truncated and not explanatory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loaded, but the example JSON is long, truncated mid-object, and not formatted for easy scanning. It is concise but the incomplete example hurts clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not describe the return value, which is a list of roles, nor the meaning of 'after'/'first' for pagination, or the structure of order. The example partially compensates but is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3. The description adds an example showing the structure of filter/notFilter, which gives some extra meaning beyond 'GraphQL: RoleFilter', but does not explain each parameter or value formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query roles' which is a specific verb+resource, clearly indicating this tool lists/queries role objects. The plural 'roles' distinguishes it from sibling 'role' (singular) which likely fetches a single role, though not explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'role' or 'create_role'. The example variables imply usage for filtering/pagination but there is no stated context or exclusions, leaving the agent to infer suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only labels the operation as a 'mutation', which implies state changes, but does not explain side effects, required permissions, irreversibility, or what happens to omitted fields. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the operation type, followed by a compact example. The example JSON is lengthy but necessary to convey the input structure. No unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should cover what the mutation returns, any constraints (e.g., required fields within input), and how it interacts with related case operations. It only provides a raw example, leaving significant gaps for choosing and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's description for 'input' is merely 'GraphQL: UpdateCaseInput!', which is unhelpful. The example variables add significant meaning by showing the expected structure, including fields like caseId, severity, state, and expirationDate. This helps an agent construct a valid input object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially 'Cases · mutation updateCase' which restates the tool name and category, but the included example variables show the updatable fields (severity, state, title, etc.), implying it updates case attributes. It does not explicitly say 'Updates a case' or distinguish from related tools like close_case or update_case_due_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of using update_case_due_date for due-date-specific changes or close_case for closing. The description provides no exclusions, prerequisites, or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Query' implies read-only, but the description does not explain return format, pagination, permissions, or other side effects. This is inadequate for a safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded with the key action. No wasted words, though the brevity comes at the cost of missing useful context. It is concise but not overly so for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple 1-parameter schema, the tool belongs to a large family of access control tools. The description does not clarify what 'accessControlResources' refers to or what the output looks like, leaving a significant gap for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single `customer_slug` parameter with a clear description. The tool description's example variables '{}' reinforces optionality but adds no further semantic value, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('query') and resource ('accessControlResources'), which identifies the tool's basic purpose. However, it does not differentiate from sibling access control tools (e.g., access_control_policies, access_group), and what constitutes 'resources' remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention specific use cases, prerequisites, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'mutation' and shows the expected input, with no mention of write side effects, required permissions, error behavior, or return value. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded, containing a label and an example. It avoids unnecessary detail. However, the cryptic 'Cases · mutation addCaseComment' phrase could be more readable, and the example is essential to understanding the usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation, the example provides enough to construct a basic call, but the description lacks usage guidelines, behavioral context, and return value information. With no output schema, the description should at least mention what the mutation accomplishes or returns. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's description of the required 'input' parameter is merely 'GraphQL: CaseCommentInput!', which is opaque. The tool description compensates by providing an example structure with 'caseId' and 'comment', adding meaningful semantics beyond the schema. The optional 'customer_slug' is already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this is a GraphQL mutation to add a case comment, with example variables showing 'caseId' and 'comment'. The 'Cases ·' prefix helps distinguish it from sibling comment tools like add_incident_comment and add_task_comment, though it lacks a plain-language verb phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Multiple sibling tools exist for adding comments to different entities, but the description does not mention them or any selection criteria, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'query' implying read-only, but does not mention pagination behavior, return format, or any side effects. The example shows pagination variables but does not explain how they affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with a long example. It is front-loaded with the purpose, but the variable listing and truncated example make it less concise and harder to parse. Some structure (e.g., bullet list of variables) would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what the tool returns, how to interpret the response, or how to use the parameters beyond a partial example. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal ('GraphQL: String'), but the tool description lists all variable names and provides an example with structural hints (e.g., filter object containing customers, ids, name, pods, roles, users). This adds meaning beyond the schema by showing how parameters interrelate, though the example is truncated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'query apiKeys' which identifies the verb and resource, distinguishing it from sibling tools like create_api_key and delete_api_key. However, it does not explicitly describe the returned data or scope (e.g., list vs. search), so it is not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like create_api_key or delete_api_key, nor does it mention any prerequisites or scenarios. This is a significant gap for a query tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'query', implying a read operation, but with no annotations provided, the agent cannot know about pagination behavior, rate limits, or permissions. It does not disclose any side effects or additional behavioral traits beyond what 'query' implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line plus one example JSON block, which is compact and includes a helpful example without extra prose. It is efficient and front-loaded with the operation name and variables.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return shape, pagination semantics beyond the presence of after/first, or the meaning of filter fields. For a GraphQL query tool, this is sparse; the example helps but leaves many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists variables after, filter, first, order and provides a JSON example showing how to structure filter and order, which adds some value beyond the schema's minimal 'GraphQL: String' descriptions. However, it omits the customer_slug parameter, and the schema descriptions are just type references, so the example only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'query customerPlaybooks', providing a specific verb and resource. It distinguishes from mutation siblings like upsert_customer_playbook, but does not explicitly differentiate from the sibling 'playbooks' beyond the customer prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as playbooks or recommended_playbooks. The description only lists variables and an example, with no mention of use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only labels the operation as a 'mutation', which implies a write, but does not mention irreversibility, permission requirements, side effects, rate limits, or any other safety-relevant details. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one line with a clear header ('API Keys · mutation deleteApiKeyById') and an example. It is front-loaded and contains no redundant filler, though the formatting with '·' is slightly unusual.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate by explaining the deletion's effects, when to use it, and how it differs from other deletion tools. It provides none of that, leaving the agent with insufficient context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all three parameters. The description adds an example variables object but omits the 'customer_slug' parameter and does not explain the meaning of 'id' or 'user' beyond the schema's GraphQL type hints, adding minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as a mutation to delete an API key by ID via the phrase 'deleteApiKeyById', which is clear and matches the tool name. However, it does not explicitly describe the action in a full sentence or differentiate from the sibling tool 'delete_api_keys', which may handle bulk deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'delete_api_keys', no prerequisites, and no exclusions. It only lists variables and an example, leaving the agent without contextual information for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It merely states that it is a 'mutation' but does not explain the destructive scope, whether it deletes all API keys for the user, or any security or confirmation implications. This lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the resource and operation type. It avoids verbosity, though the phrase 'API Keys · mutation deleteApiKeys' partially duplicates the tool name. Overall, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description is too sparse. It fails to specify whether it deletes all API keys for a user or a specific set, and it omits context about potential side effects. This ambiguity is especially problematic given the sibling 'delete_api_key_by_id'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for both parameters ('user' and 'customer_slug'), so the description adds minimal value. It provides an example for 'user' but does not explain the purpose of 'customer_slug' or how parameters relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a mutation to delete API keys, and the variable 'user' indicates the target. However, it does not distinguish this from the sibling tool 'delete_api_key_by_id', leaving the exact scope (e.g., all keys for a user vs. a single key) ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'delete_api_key_by_id' or 'create_api_key'. It only lists variables with an example, but no exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states it's a 'mutation' and shows variables. It does not mention permanence, side effects, permissions, or what happens to the contact, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single compact line that identifies the category, mutation name, and variables. Every token earns its place, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema and no annotations, the description should at least explicitly state the action and any consequences. It fails to do so, relying entirely on the mutation name and schema, leaving the agent without necessary context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters, including descriptions for 'id' and 'customer_slug'. The description adds an example variable format, but this is redundant with the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The mutation name 'deleteEmergencyContact' clearly indicates the tool deletes an emergency contact, and the inclusion of 'Emergency Contacts' provides context. It is distinct from sibling tools like 'create_emergency_contact' and 'update_emergency_contact', though the description lacks an explicit natural-language statement of the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for deletion. The description only lists variables and an example, omitting any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It identifies the operation as a 'mutation' (implying a write/destructive action) but provides no details about consequences, reversibility, idempotency, or required permissions. The user is left unaware of potential side effects or safeguards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single summary line plus an example. It avoids filler and gets directly to the point. The example variable block is useful for immediate invocation. It could be slightly more descriptive, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a delete operation with no annotations, output schema, or side-effect disclosure, the description is incomplete for safe usage. It lacks warnings or context about what happens when a pod is deleted, and there is no guidance on prerequisites. The schema covers parameters, but the overall context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds 'Variables: id' and an example for id, but this is redundant with the schema. It adds no new semantic information beyond what's already present, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes 'mutation deletePod' which clearly indicates a delete operation on a pod. The tool name itself is highly explicit. While it doesn't use a full sentence like 'Deletes a pod,' the mutation name leaves no ambiguity about the action and target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like delete_access_group or update_pod. There is no mention of prerequisites, conditions, or typical use cases. The description only provides the mutation name and an example variable, offering no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It only restates that the operation is a mutation and deletion, without noting irreversibility, authorization requirements, or effects on related entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and avoids redundant prose. It front-loads the operation type and required variable, and the example placeholder provides a quick template, though the wording is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify return behavior, side effects, and multi-tenant context. It only supplies the id and domain label, leaving the caller to infer what happens after deletion or how customer_slug is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents id and customer_slug. The description adds an example variable block but no additional semantic meaning beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as a deleteRole mutation within Access Groups and requires an id, making the tool's purpose clear. However, it never states in plain language that it deletes a role and does not explicitly distinguish it from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_role, update_role, or delete_access_group. The Access Groups prefix implies a domain but gives no selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The example variables reveal cursor-based pagination (after, first) and filtering/sorting capability, which adds some behavioral context beyond the empty annotations. However, it does not state that the operation is read-only, what data is returned, or any rate limits or other constraints, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with no wasted words. The example is useful, though the leading 'Fields ·' is cryptic and not a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters but the description omits 'customer_slug' entirely. There is no output schema, and the description does not describe return values, error behavior, or how this query fits with siblings. The example hints at pagination but is insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal ('GraphQL: String'), but the example provides concrete values and nested JSON structure for 'filter' and 'order', significantly aiding parameter understanding. This adds meaningful value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as a query for grey matter fields ('Fields · query greymatterFields'), which is more specific than a tautology, but it lacks a clear verb like 'list' or 'retrieve' and does not explain what grey matter fields are or what the query returns. It is somewhat redundant with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus the singular 'greymatter_field' or other query tools. The description gives variables and an example but no context about typical use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing side effects, permissions, reversibility, and error handling. The description merely labels it as a 'mutation' and gives an example, but does not explain whether removing a child is destructive, if it can be undone, what happens if the child does not exist, or what access rights are required. This is a significant transparency gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the category 'Cases · mutation'. The example variables are compact and structured. Every element earns its place, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation removing a child from a case, the description lacks critical context: what actually happens (deletion vs unlinking), whether the child is removed permanently, what return value to expect, and how it interacts with related tools like add_children_to_case. The example helps with input structure but does not address these gaps. No output schema exists, so the description should explain outcomes but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for both parameters, but the 'input' description is just 'GraphQL: RemoveChildFromCaseInput!' with no internal structure. The example variables in the description compensate by revealing the expected shape (caseId, child with childId and childType). This adds meaning beyond the schema, but it does not explain allowed childType values, whether childId is required for all types, or the role of customer_slug beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'mutation removeChildFromCase' and provides an example variables block with caseId and child details, which clearly implies removing a child (e.g., a DISCOVER_TASK) from a case. The name itself is precise, and the example reinforces the action. However, it relies on the tool name and example rather than an explicit verbal description, and does not distinguish from siblings beyond the 'remove' vs 'add' contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like add_children_to_case, nor any mention of prerequisites, conditions, or scenarios where this mutation should be invoked. The example variables show how to call it but not why or when. This leaves the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'execute', which hints at a mutation but does not disclose side effects, whether it creates a playbook run, what happens on failure, or what the response contains. The example payload gives structural clues but not behavioral outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief in words but contains a large JSON example that dominates the entry, making it less scannable. The phrase 'Variables: input.' is redundant with the schema. The example is useful but could be formatted more compactly or explained with a few field notes. Overall, it is not overly long, but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description should clarify what the tool returns, what side effects occur, and any constraints. It provides neither. It also does not reference related tools like playbook_run or explain how this action is recorded. The complex nested input is documented, but the surrounding context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'input' as 'GraphQL: RunPlaybookInput!', which is minimally informative. The description compensates by providing a detailed example of the expected input structure, including nested fields like integrationIds and playbookVariables, adding practical meaning. However, it omits any explanation of the optional customer_slug parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Execute a predefined playbook' with the qualifier 'Respond capability'. This makes the primary intent clear and distinguishes it from query-style siblings like playbook_run or playbook_runs, though it does not 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage by saying 'Execute', but it does not mention when a user should prefer this over related playbook tools, nor any prerequisites or exclusions. There is no context on conditions, such as needing specific permissions or a prior playbook definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only gives a GraphQL query example. It doesn't mention pagination semantics (though 'after' and 'first' hint at it), return format, authentication requirements, or side effects. The example is a static variable set, not behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, leading with the operation name, then variables, then an example. The example is somewhat verbose but packed with useful details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't state what the tool returns (e.g., a list of policies, pagination info), the meaning of 'customerId' vs 'customer_slug', or any defaults/constraints. The example is a starting point but insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal (just type names), so the description adds value by listing all parameters and providing an example that shows nested structures for 'policyFilter' and 'policyOrder'. This helps infer expected formats beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query accessControlPolicies', which clearly identifies the operation as a query for access control policies. It uses a specific verb and resource, and the plural form suggests listing, though it doesn't explicitly differentiate from the singular 'access_control_policy' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'access_control_policy' (singular) or 'create_access_control_policy'. The description only lists variables and an example, without stating any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention side effects, permissions, whether the action is reversible, or any implications of the 'autoAssign' field. The tool appears to be a mutation (acknowledge), but the description provides no details on state changes or postconditions beyond the input structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but a bit repetitive ('input:' and 'Variables: input' restate the same thing). It is reasonably short, but the structure is awkward and could be more concise. It does include the essential example, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple mutation with no output schema, and the description provides the input shape and example. However, it lacks usage context, behavioral details, and any mention of the optional 'customer_slug' parameter (though that's covered by the schema). For a straightforward action, this is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema for the 'input' field only references 'GraphQL: IncidentAcknowledgementInput!', which is minimal. The description compensates by listing the fields (incidentId, acknowledgementMethod, autoAssign) and providing an example JSON, giving the agent concrete guidance. This is significant added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Acknowledge' with the resource 'incident', clearly indicating the action and target. It also lists the input fields, which helps define the scope. However, it does not explicitly distinguish this from sibling tools like 'acknowledge_assign_and_close_incident' or 'close_incident', so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It only states 'Acknowledge an incident' and gives an example, but there is no mention of exclusions, prerequisites, or context such as 'use this when you only want to acknowledge without closing.' This leaves the decision to the agent without comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'mutation' and gives an example. It does not mention whether the operation is additive/idempotent, what permissions are required, what side effects occur, or what the response contains. The mutation status is already evident from the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the operation domain and mutation name. The example is compact and useful, though the 'Variables: input' line adds little beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with no annotations, output schema, or nested schema details, the description is incomplete. It gives an example payload but omits semantics, constraints, return values, and error/edge-case behavior, so an agent would likely need to make assumptions before invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a GraphQL type reference for input, so the example variables add essential structure: input.caseId, input.children.childId, and input.children.childType. This compensates for the opaque schema, though only one childType example (DISCOVER_TASK) is shown and customer_slug is not addressed in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as 'mutation addChildrenToCase' and provides an example payload with caseId and childType DISCOVER_TASK, making the core action of adding child objects to a case discernible. It lacks a plain-language explanation of 'children' and does not explicitly contrast with related case mutations, but the verb+resource mapping is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as remove_child_from_case or add_case_comment. The description only labels the operation and shows an example; there are no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the word 'query' implies a read-only operation, but this is not explicitly stated. The description offers example filter/order structures but omits pagination behavior, return format, and the customer_slug header override semantics, which are left to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact line with a dense example JSON. It is efficient and front-loaded, though the large example may reduce readability. No filler words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or return-value description is provided, so the agent cannot infer what the tool returns. The tool's purpose as a paginated list query is implied but not stated, and the interaction with customer_slug is only in the schema. The description is not complete for a 5-parameter query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are minimal ('GraphQL: String'), but the example variable block adds concrete meaning for after, first, filter, and order, showing nested structures like callCategories and greyMatterUser. This goes beyond the schema, though customer_slug is only covered by the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates 'query emergencyContacts' with plural, implying a list operation, and distinguishes from the singular sibling 'emergency_contact'. However, it does not explicitly say 'list all' or 'search', so the purpose is clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'emergency_contact' (singular) or create/update/delete variants. The description only provides a query template, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only lists variables and provides an example filter structure, but does not explicitly state read-only behavior, pagination semantics, or any side effects. The example adds minor context but lacks substantial behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The example JSON is verbose but serves as valuable documentation. It earns its place by illustrating the filter structure, keeping the overall description efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description fails to explain return values, pagination behavior, or the customer_slug override. The example variables provide some insight, but the tool feels under-documented for a 5-parameter query with nested filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with generic types, but the description adds a concrete example showing the shape of filter and order, including nested fields like created, groups, roles, and workLocations. This clarifies the intended use of the filter parameter significantly, though it omits the customer_slug parameter from the variable list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'query identities' with the specific resource, which is clear. It distinguishes from sibling tools by resource name (identities vs users, etc.), though the wording is terse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context, leaving the agent to infer usage solely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'query,' which implies a read-only operation, but it does not disclose return format, whether any side effects exist, authentication requirements, or any other behavioral traits. The example only shows the input shape, not the output 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with a concise prefix and a useful example. It doesn't contain filler, but the 'Indicators ·' prefix is slightly redundant with the tool name. Overall, it is appropriately sized for the content it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain return values, but it does not. It only covers the input format, leaving the agent guessing about what the query returns. For a simple query tool, this is a significant gap, as the agent cannot anticipate the response structure or any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'by' as 'GraphQL: IOCBy!' and 'customer_slug' as an override header, which is minimal. The description enriches this by providing a concrete example of the 'by' object structure with id, input, name, and type, helping the agent understand the expected format beyond the schema. This adds meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query indicator,' which clearly identifies the action (query) and resource (indicator). The example variables further clarify that it retrieves a single indicator by ID and input criteria, distinguishing it from the plural 'indicators' sibling. However, it does not explicitly say 'get indicator by ID' or describe the full scope of the query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling 'indicators' likely lists all indicators, but the description does not explicitly state 'use this to fetch a single indicator' or mention any exclusions. The usage context is only implied by the singular naming and example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It indicates a read-only operation via the word 'query', but offers no additional context such as permissions, pagination, or return behavior. For a query tool, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line plus an example. It is front-loaded and contains no fluff. However, its brevity borders on under-specification, but the example adds valuable context, so it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not state what the query returns or what fields are available. The filter semantics are only partially illustrated via the example. Given the presence of sibling playbook-related tools, this description is incomplete for an agent to fully understand the tool's scope and result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'filter' is merely a type reference ('GraphQL: RecommendedPlaybookFilter!'), providing no semantic meaning. The description compensates by giving an example structure with 'artifacts' and 'tempRuleId', which adds practical guidance beyond the schema. The 'customer_slug' parameter is adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation as 'query recommendedPlaybooks', which clearly identifies the action (query) and the resource (recommended playbooks). It distinguishes from siblings like 'playbooks' or 'customer_playbooks' by specifying the 'recommended' variant, though it does not elaborate on what 'recommended' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'playbooks' or 'customer_playbooks'. No exclusions or context are given, leaving the agent to infer usage from the name and example filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'query' which hints at read-only, but doesn't explicitly state that it returns a list of reference lists or that it has no side effects. It also doesn't mention pagination behavior, error conditions, or the effect of the customer_slug override. The example adds some clarity about filtering/ordering but leaves the return format and other behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief—two sentence fragments and an example. It front-loads the core purpose ('query referenceLists') and then provides the most useful supplementary detail (the variables and example). No waste, but it is so terse that it borders on under-specification. Still, for what it includes, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns, but it doesn't. It also omits any explanation of the customer_slug parameter, which is not shown in the variable list or example. Given the presence of nested filter/order objects and a missing output description, the tool description is incomplete and leaves several gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides GraphQL type names (e.g., 'GraphQL: ReferenceListFilter'), which are not meaningful. The description compensates by listing the variables and giving a concrete JSON example that reveals the structure of the 'filter' object (dataTagging, queryReference, search) and 'order' object (direction, orderBy). This adds significant semantic value beyond the schema, though the meaning of individual fields (e.g., dataTagging) is still not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'query referenceLists', which identifies a read operation on a plural resource, distinguishing it from the many mutation tools (create/update/delete). The plural name and the presence of pagination variables imply a list query. However, it doesn't explicitly distinguish from the singular 'reference_list' tool, which likely fetches a single list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'reference_list' (singular) or the create/update/delete operations. It doesn't mention any prerequisites, exclusions, or context where this tool is preferred. The only signal is the plural name and the query verb, which is implicit at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that this is a read-only query operation and exposes pagination/filtering variables (after, first, incidentFilter, incidentOrder). However, it does not explain the meaning of the returned data, potential limitations, or any behavioral details like rate limits or required auth. Since annotations are absent, the description carries some burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The example variables add useful context but are truncated, which slightly detracts from clarity. Overall, it's concise and every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a query tool with 5 parameters and no output schema or annotations. The description provides a list of variables and a partial example, but it omits critical context such as what the returned data looks like, how to use pagination effectively, and the difference between this and the sibling 'incidents' tool. Given the availability of many incident-related tools, this is insufficient for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides type labels (e.g., 'GraphQL: String'), so semantic meaning is lacking. The description compensates by listing variable names and providing an example that illustrates the structure of incidentFilter, including acknowledged, assignees, closed, created, and escalated. However, it doesn't clarify the meaning of 'after', 'first', or 'incidentOrder' beyond the example, so full semantic coverage is not achieved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a query for 'healthIncidents' and lists the supported variables. It uses the verb 'query' and names the resource specifically. However, it does not explicitly differentiate from the sibling 'incidents' tool, so it's not 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.
Usage Guidelines2/5
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 like 'incidents' or other incident-related tools. The description only mentions the operation and variables, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that the response includes comments, artifacts, metadata, rule, and assignee, which is useful, but it does not state that this is a read-only operation, require no special permissions, or describe pagination behavior or potential 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not concise: it includes a long list of variable names that are already present in the schema, adding noise. The first sentence is clear, but the rest is a cluttered dump with an incomplete example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (35 optional parameters, no output schema, no annotations), the description is insufficient. It does not explain how to specify an id vs ticket number via 'by', how pagination works with after/first variables, or what the return shape looks like. The truncated example only partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 lists variable names and provides an example, but does not explain the key 'by' parameter or the meaning of the numerous nested filters and orders. The example is truncated, reducing its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single incident by id or ticket number', specifying a verb, resource, and scope. This distinguishes it from sibling tools like 'incidents' which likely list multiple incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single incident is needed, but does not explicitly mention alternatives or when not to use this tool. Sibling tools such as 'incidents' exist but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'query indicators' and lists variables, without explaining response format, pagination behavior, or potential side effects (though it appears read-only). The example does reveal some filtering fields, but not the overall behavior or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence and an example. It is slightly front-loaded with the name and verb. The example is long but provides necessary detail about the filter structure. Overall, it earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, so the description must compensate. The example aids understanding of the query parameters, but the description does not state what the tool returns or when to use it. It is adequate for a basic query tool but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters but with shallow descriptions like 'GraphQL: String'. The description provides a rich example that illustrates the nested structure of 'filter' (feedNames, lastSeenAt, names, severity, type) and 'order' (direction, orderBy), adding meaning beyond the schema's simple type annotations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'query indicators', which is a clear verb-resource relationship. The example variables provide concrete detail on the query capabilities. However, it does not explicitly distinguish from the sibling tool 'indicator' (singular), leaving some ambiguity about whether this is a list or single-item operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only shows a query example with variables but does not mention when this tool is appropriate, what it returns, or when to prefer the singular 'indicator' tool. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action and input. It does not mention whether resolution is reversible, what side effects occur, required permissions, or what the response looks like. Additionally, the unexplained after/filter/first/order variables add confusion about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose ('Resolve a task'), then provides the input structure and an illustrative example. It is relatively compact, though the example JSON is somewhat lengthy. The structure is logical and avoids unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description must carry the full contextual burden. It explains the core action and input but fails to clarify the extra query parameters, the return value, or the operational consequences. For a tool with 6 parameters, this is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the descriptions are minimal (e.g., 'GraphQL: String'). The description adds value by listing the ResolveTaskInput fields (taskId, closeCode, closeNote) and providing example values. However, the after/filter/first/order parameters are only shown in the example without explanation, leaving their purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resolve a task' with a specific verb and resource, and the closeCode enum values (CANCELLED, DUPLICATE, RESOLVED) add specificity. It is distinct from sibling tools like unresolve_task and bulk_resolve_tasks, which are named differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as bulk_resolve_tasks, unresolve_task, or update_task_state. It lacks context about prerequisites (e.g., task must be open) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It identifies the operation as a mutation and shows the comment ID parameter, but does not state that the deletion is permanent, irreversible, or any side effects. This is thin for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with a category prefix and an example. It front-loads the operation type and gives the exact variable shape without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no output schema, the description is minimally adequate: it identifies the action and gives an example. However, it omits any statement of effect (e.g., permanently deletes the comment) which would be expected when annotations provide no safety information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters, giving 100% coverage, but the description adds a concrete example showing the nested drpAlertComment ID field inside input. This helps agents construct valid variables beyond what the schema's generic GraphQL type name provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the operation as a mutation deleteDrpAlertComment, clearly indicating it deletes a DRP alert comment. It includes the resource and action, though it largely mirrors the tool name without elaborating on what 'DRP alert comment' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like update_drp_alert_comment or add_drp_alert_comment. The description only states the operation type and example variables, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the tool accepts 'after', 'filter', 'first', and 'orderBy' variables, and the example illustrates filtering by fields like 'active' and 'assetTypes'. However, it does not reveal return format, pagination behavior, rate limits, or the fact that it also accepts 'customer_slug'. The read-only nature is implied by 'query' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear front-loaded phrase 'DRP Alerts · query drpAlerts', but then becomes a long run-on sentence with a truncated JSON example. The truncation ('...') makes it feel incomplete and less structured than it could be. It is not excessively long but could be more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain return values or result shape. The filter object is left generic in the schema, and the example is truncated before all filter fields are shown. The tool appears moderately complex (5 params, nested filter object), but the description does not fully compensate for the missing details, especially around pagination and filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are generic ('GraphQL: String', etc.) but cover all 5 parameters (100% coverage), so the baseline is 3. The description adds value by showing example filter fields, but it omits 'customer_slug' from the listed variables and the example is truncated, leaving the filter structure incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as 'query drpAlerts', which is a specific verb+resource pair. It implies the tool fetches alert data. However, it does not explicitly differentiate from the singular 'drp_alert' tool or other alert-related query variants, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example of variables, which implicitly shows how to construct a query, but it does not state when to use this tool versus alternatives like 'drp_alert' or mutation tools. There is no explicit exclusion or alternative guidance, only an implied usage pattern from the example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only says 'Fetch a single task by id, including comments' – implying read-only behavior but never explicitly stating it. The massive variable list without explanation obscures pagination and nested-connection behavior rather than illuminating it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear purpose but immediately devolves into a long run-on list of 50 variable names that duplicates the schema. This list is unstructured and not front-loaded; the useful example is buried at the end. The description would be far more concise and effective by omitting the variable list entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 50 parameters, no output schema, and no annotations, the description should explain the interplay of nested connections (activity logs, access groups, pods, roles) and how the many filter/order/cursor parameters relate. It only mentions comments, leaving most of the tool's behavior unexplained and failing to provide a complete operative picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are merely GraphQL type names (e.g., 'GraphQL: String'), so they convey little semantic meaning. The description attempts to compensate with an example object showing shapes for 'filter', 'order', etc., which adds some value. However, the example is truncated and the raw variable-name dump is redundant, so the added meaning is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('a single task'), and the scope ('by id, including comments'). This distinguishes it from sibling tools like 'tasks' (list) and 'create_task' (create). The core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys the primary use case: retrieve one specific task by ID, optionally including its comments. While it does not explicitly name alternatives or exclusions, the singular 'by id' framing provides clear context for when this tool is appropriate versus a list/filter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses 'Relay-paginated' behavior and provides example variables showing filter structure, which adds value beyond the annotation-less schema. However, it omits other behavioral details like authentication requirements, rate limits, default ordering, or return shape. No annotations are present, so the description carries partial burden but not fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, then follows with pagination and example variables. The example is lengthy but useful for understanding complex filter structures, and every sentence contributes meaning. No filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pagination, filtering) and lack of an output schema, the description covers pagination and filter examples but does not describe the response shape or ordering field options. The scope qualifier and example help, but gaps remain around error handling and full filter fields. It is adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names the key GraphQL variables (after, first, taskFilter, taskOrder) and gives a concrete example of taskFilter with nested fields like acknowledged, assignees, closed, created, and notAssignees, which adds meaning beyond the schema's bare type descriptions. The customer_slug parameter is not mentioned in the description, but its schema description provides context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List tasks' with a specific scope qualifier '(non-security / engineering items)' and mentions filtering and ordering, which conveys the tool's function. It does not explicitly differentiate from sibling tools like 'task' or 'discover_tasks', but the verb and resource are clear enough to establish primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'non-security / engineering items' implies a scope limitation but does not mention when-not-to-use or point to other task-related tools. Sibling tools such as 'discover_tasks' or 'resolve_task' exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It notes that MITRE ATT&CK mapping is included "where available," which is useful context about the output. However, it does not mention read-only behavior, pagination defaults, required permissions, or the meaning of "deployed." The example variables hint at filter structure but add only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main sentence is concise and front-loaded with the core purpose. The variable list and example are useful but the example is abruptly truncated mid-string, which hurts readability. Overall, it is reasonably concise but lacks polish in the example presentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description should clarify return value structure, pagination behavior, and operational context. It mentions the list includes MITRE mapping and provides a filter example, but it does not explain how pagination works (after/first), what "deployed" means, or what fields are returned. The description is adequate for a basic list call but leaves gaps that the schema and annotations do not fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for parameters are unhelpful (just "GraphQL: String", etc.), so the description's example variables add real value by illustrating the structure of filter, detectionRuleOrder, and after. This goes beyond the schema, though the example is truncated and does not fully explain all parameters (e.g., first).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "List deployed detection rules across GreyMatter integrations (includes MITRE ATT&CK mapping where available)." The verb "List" specifies the action, and the resource and scope are explicit. This distinguishes it from sibling tools like customer_detections, which likely focuses on customer-specific detections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as customer_detections or detection_rule (singular). It does not mention prerequisites, suitability for specific use cases, or exclusions. The only hint is the word "deployed," implying a focus on active rules, but this is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 returns usage and mentions the limit, which is useful context. However, it does not explicitly disclose that it is a read-only operation with no side effects, nor does it describe the response fields (e.g., points used, remaining, reset time).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with useful information, but the trailing 'Example variables: {}' is unnecessary noise that adds no value. It is mostly concise but not perfectly clean, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional parameter, no output schema, no annotations), and the description explains the core purpose. However, it fails to describe what the returned 'usage' actually contains (e.g., current points, limit, quota) or how to interpret the result, which is a notable gap given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single optional parameter (customer_slug), with a clear description in the schema. The tool description does not mention the parameter or add any additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('current GreyMatter API rate-limit usage'), clearly stating what the tool does. It also adds useful context about the 5000 points/hour limit, and none of the sibling tools relate to rate limiting, so it is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a read-only monitoring tool for checking API quota, but it does not explicitly state when to use it (e.g., 'before making bulk calls') or contrast it with any alternatives. There are no direct siblings, so explicit exclusion is not needed, but the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the fields and gives an example, but omits side effects, permission requirements, whether the state change is reversible, or what the response looks like. The description is mostly structural, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear purpose, then provides the input structure and an example. The example JSON is somewhat verbose but useful for understanding the exact format. It is compact enough, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description covers the basics but leaves gaps: it does not enumerate all valid state values, clarify whether the comment is required, explain the customer_slug override, or relate this tool to specialized incident actions like close_incident or acknowledge_incident. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'GraphQL: UpdateIncidentStateInput!' for the input parameter, but the description unpacks the nested fields (incidentId, state, comment) and provides a complete example with variable syntax. This adds meaningful context beyond the schema, though customer_slug is not explained beyond its own schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Change an incident's state' with concrete examples (PENDING_RQ, PENDING_CUSTOMER), distinguishing it from sibling tools that target different resources (e.g., update_drp_alert_state) or specialized actions (e.g., close_incident). The verb+resource is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this to change an incident's state. However, it does not explicitly mention when to prefer this over specialized state transition tools like acknowledge_incident or close_incident, nor does it provide exclusions or alternative tool references. Clear context exists but lacks differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without covering side effects, permissions, return values, or idempotency. The inclusion of query-like parameters (after, filter, first, order) in a mutation is unexplained, which adds confusion rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear action sentence, followed by a parameter list and an example. The example JSON is helpful but somewhat verbose; still, it is kept to a single line and is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple mutation, but with no annotations or output schema, the description should at least hint at the return value or any preconditions. The presence of pagination/filter variables without explanation leaves the tool's full behavior unclear, so completeness is only average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% coverage, the descriptions are minimal (e.g., 'GraphQL: String'). The description adds value by specifying that input expects TaskCommentInput { taskId, comment } and providing a full example variable set, which clarifies how to construct the payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a comment to a task,' which is a specific verb and resource. It distinguishes this tool from sibling comment tools for other entities (e.g., add_case_comment, add_incident_comment, add_drp_alert_comment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need to add a comment to a task. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough to avoid confusion with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior traits. It mentions the input structure and example but does not state required permissions, idempotency, reversibility, or side effects. This is a mutation tool, and the description lacks such transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and each sentence adds useful information (input fields, resolution hint, example). It is somewhat repetitive in mentioning GraphQL syntax, but overall all content is earn-worthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of an assignment operation, the description gives enough to invoke the tool correctly: input shape, how to resolve assigneeId, and an example. It does not mention return values or permissions, but for a simple mutation with no output schema this is a reasonable completeness level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows an opaque 'input' property and a customer_slug override, but the description explicitly names the inner fields 'incidentId' and 'assigneeId', and provides an example. This adds valuable meaning beyond the schema's placeholder, compensating for the opaque GraphQL type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Assign an incident to a GreyMatter user,' identifying the specific verb (assign) and resource (incident). It distinguishes from sibling tools like assign_task or assign_drp_alert by focusing on incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable guidance: 'Resolve assigneeId via the customer/users query,' and includes an example with variable names. It implies the tool is for assigning incidents but does not explicitly name alternatives or exclusion cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states the action (resolve/cancel) and lists close codes, but does not mention permanence, required permissions, side effects on the incident, or what the response looks like. The example adds usage detail but not behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then provides structured parameter details, enum values, and an example. It is somewhat dense but every sentence adds value; no filler words. An example is included, which improves usability without being redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers the request structure thoroughly and includes an example. However, it does not explain return values, error cases, or when to prefer this over sibling close/state tools. It is nearly complete for the core action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a bare type name ('GraphQL: CloseIncidentRequest') and a header override note. The description compensates richly by detailing the request fields (incidentId, state, closeCode, closeNote), enumerating all allowed close codes, and giving a concrete JSON example. This far exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Resolve or cancel an incident' – a specific verb and resource. It clearly distinguishes from sibling tools like update_incident_state or acknowledge_incident by specifying the RESOLVED/CANCELLED states and close codes, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used to close incidents by providing state and close code options, but it does not explicitly mention when not to use it or compare with siblings like bulk_close_incidents or acknowledge_assign_and_close_incident. Context is clear, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds one piece of behavioral context: read-only mode rejects mutation documents. However, it does not disclose the potentially destructive nature of arbitrary GraphQL mutations, authentication requirements, or error/response behavior, leaving significant gaps for a raw query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, with no filler. Each sentence delivers essential information: purpose, use case, required input, and a behavioral caveat. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic GraphQL proxy tool, the description covers the core purpose, usage guidance, and a key behavior (read-only mode). It does not mention the customer_slug override or response format, but the schema covers parameters and GraphQL responses are self-describing. Overall, it is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds value by emphasizing 'the full query/mutation string' and an 'optional variables object', reinforcing parameter usage. It does not mention customer_slug, but the schema's description sufficiently explains it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run an arbitrary GraphQL document against the GreyMatter API', identifying both the action and the resource. It also distinguishes itself from siblings by noting 'Use this for operations not covered by a dedicated tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'for operations not covered by a dedicated tool', which inherently defines the alternative (dedicated tools). It also provides practical instructions on providing the query and variables, plus a caveat about read-only mode rejecting mutations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the burden. It discloses Relay pagination, common states, and variable structure, which gives a clear behavioral picture. 'List' implies a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then provides essential details on pagination, states, and variables. The example is useful but a bit lengthy; still well-organized and each part contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description covers the return envelope (edges/pageInfo/totalCount) and mentions filtering and ordering. It could detail node fields, but for a list tool this is adequate and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are minimal ('GraphQL: String'), offering little meaning. The description compensates by listing variables and providing a concrete example of the incidentFilter structure, adding significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('List security incidents') with filtering and ordering capabilities. The scope distinguishes it from singular 'incident' and other incident-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing and filtering incidents with pagination. Provides context on common states and example variables, but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It reveals pagination structure (outer vs nested), the specific page-size variables, and a workaround for a GreyMatter server-side error (omitting discoverExposure). This goes beyond the schema and provides actionable behavioral details, though it does not mention potential side effects or output shape beyond the nested connections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but appropriately sized given 17 parameters. It front-loads the core purpose, then explains pagination, lists variables, shows an example, and ends with a caveat. Every sentence carries information, though the long example and variable enumeration make it somewhat heavy; still, it's well-structured and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (17 params), no annotations, and no output schema, the description is remarkably complete. It explains the nested structure, pagination semantics, provides a concrete example, and even includes a workaround for a known server issue. It lacks explicit response shape, but for a listing operation with this much nested detail, it covers the essential context an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are generic types like 'GraphQL: String' and empty objects, providing no real semantics. The description compensates by explaining the role of key parameters: 'first3' bounds the outer list, 'first'/'first1'/'first2' page nested connections, and all variables are listed with an example showing how to use filters and ordering. This adds substantial meaning far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List cases (with nested activity/children/comments connections)' which clearly states the action (list), resource (cases), and scope (nested connections). The plural 'cases' combined with the sibling tool 'case' (singular) distinguishes it as the list operation versus a single-case fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on pagination: 'The OUTER list page size is `first3`... `first`/`first1`/`first2` page the nested connections.' It also provides an example and a note about using graphql_query for discoverExposure, offering an explicit alternative for that field. However, it does not explicitly state when to prefer this over other case-related tools or provide exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses a critical behavioral quirk — omitting `state` causes the GreyMatter API to return success=false with no error — and gives concrete guidance to avoid that failure. It doesn't describe success response shape, but the disclosed failure mode is valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence delivers needed information: purpose, the critical state trap, required/optional enums, and a complete example. The example is long but directly usable and not wasteful. The description is front-loaded with purpose before diving into caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the opaque input schema (just a GraphQL type name) and no output schema, the description thoroughly equips an agent to invoke the tool correctly. It covers the effectively-required field, enum ranges, and a full example payload. The only minor omission is the `customer_slug` override, but that is already described in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level schema only says 'GraphQL: CreateCaseInput!' for `input`, giving no information about inner fields. The description compensates fully by explaining that `state` is effectively required, listing allowed values for `type` and `severity`, and providing a complete example variables object. This is far beyond the schema's own semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a case' — a specific verb and resource. It clearly distinguishes this from sibling tools like update_case, close_case, and cancel_case, and reinforces the purpose with details about required fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance: it explicitly warns that `state` is effectively required despite being schema-optional, and specifies which enum values are valid for `type` and `severity`. It does not explicitly compare against alternatives like update_case, but the usage context is clear enough for an agent to know when to create versus update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Reliaquest-Greymatter-MCP-Server MCP server

Copy to your README.md:

[![Reliaquest-Greymatter-MCP-Server MCP server](https://glama.ai/mcp/servers/Space-C0wboy/Reliaquest-Greymatter-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/Space-C0wboy/Reliaquest-Greymatter-MCP-Server)

Score Badge

Copy to your README.md:

[![Reliaquest-Greymatter-MCP-Server MCP server](https://glama.ai/mcp/servers/Space-C0wboy/Reliaquest-Greymatter-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/Space-C0wboy/Reliaquest-Greymatter-MCP-Server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Space-C0wboy/Reliaquest-Greymatter-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server