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

No annotations exist, so the description carries full burden. It states the return format and auto-parsing behavior, and implies that this tool lacks input validation and response handling compared to dedicated tools. However, it does not mention potential side effects, destructive actions, or rate limits, which would enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences that are perfectly front-loaded with purpose, each earning its place. No redundant phrases or unnecessary detail. Highly efficient.

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

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

Given no output schema, description fully covers return values (`{status, contentType, body}`) and auto-parsing. All five parameters are described adequately, and the escape-hatch nature is fully contextualized with sibling tool references.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond the schema: explains that `body` is ignored for GET/DELETE, describes the wrapped request format, details URL construction, and clarifies defaults. This provides agents with practical usage context.

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

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

Description clearly states it is an 'escape hatch for invoking any configuration-package REST service' and gives the URL pattern. It distinguishes itself by listing dedicated tools to prefer, making the purpose specific and unambiguous.

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

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

Explicitly tells when to use ('when no dedicated MCP tool covers the operation') and when not to ('Always prefer the specific tools'). Provides concrete examples of sibling tools, offering clear guidance on alternatives.

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

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

Without annotations, the description carries full burden. It discloses important behaviors: activities default to current user, activity type hard rule, and that tagging requires a separate guide. No contradictions with annotations (none exist).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-organized with bullet points and bold emphasis. Every sentence adds value, though some redundancy could be trimmed. Still, it's structured effectively for an AI agent.

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

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

Given no output schema, it does not describe return values, but input is thoroughly covered. References to external guides enhance completeness. For a creation tool, this is adequate, though missing response details.

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

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

Schema coverage is 100%, and the description adds substantial value beyond schema fields: detailed data types, lookup field format, date/time conversion, and real examples. This compensates for any lack of schema detail.

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

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

The description explicitly states it creates a single Creatio record, and is clearly distinguishable from sibling tools like delete, update, read, and list-entities. It specifies the operation and resource.

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

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

Provides explicit when-to-use guidance: 'Use describe-entity first to confirm required fields & types.' Also includes hard rules for activities (always set TypeId to Task unless meta flag) and default owner/author behavior. References external guides for complex cases.

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

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

With no annotations provided, the description carries full burden. It reveals the underlying request classes (InsertSysSettingRequest, PostSysSettingsValues), which adds transparency beyond a simple 'creates' statement. However, it does not disclose behavioral traits like required permissions, error behavior, rate limits, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, with the first sentence capturing the core action and the second providing a reference for further details. It is efficiently structured with no wasted words, though the guide reference could be integrated into the first sentence for better flow.

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

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

Given the tool's complexity (nested objects, many parameters, no output schema, no annotations), the description is incomplete. It does not describe return values, error handling, or success criteria. The reference to a guide partially mitigates but does not fully compensate for the lack of output schema and behavioral details.

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

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

Schema coverage is high (many parameters have descriptions in the schema itself). The description adds no new parameter semantics beyond what the schema already provides; it only points to an external guide for valueTypeName. Baseline of 3 is appropriate as description does not need to compensate.

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

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

The description clearly states the tool creates a brand-new system setting and names the specific request class (InsertSysSettingRequest) and optional value-setting service (PostSysSettingsValues). It distinguishes itself from sibling tools like 'set-sys-settings-value' (which updates existing settings) by specifying 'brand-new' and the request type.

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

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

The description implies use for creating new system settings but does not explicitly state when to use this tool vs alternatives like 'update-sys-setting-definition' or 'set-sys-settings-value'. It references a guide for valueTypeName details but provides no exclusion criteria or prerequisite conditions.

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

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

With no annotations provided, the description carries the full burden. It warns that deletion is permanent and requires confirmation, and offers a soft-delete alternative. However, it could explicitly state that the operation is irreversible and does not mention whether cascading deletes occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-line summary, followed by a numbered list of safety steps, and a clear alternative. Every sentence serves a purpose without unnecessary fluff.

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

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

Given the simplicity of a delete operation, the description covers all necessary aspects: what it does, how to use it safely, and an alternative. The schema covers parameters, and no output schema is needed for a void operation.

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

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

The input schema already fully describes both parameters (id, entity) with 100% coverage. The description does not add further semantic detail about the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states that the tool deletes a single record by ID, and the title 'Delete record in Creatio' reinforces this. It distinguishes from sibling tools like 'delete-admin-operation' which are for different purposes.

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

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

Provides explicit step-by-step instructions for safe usage: always confirm with user, show what will be deleted, ask for explicit confirmation. Also suggests a safer alternative (soft delete) using the update tool, offering clear when-to-use and when-not-to-use guidance.

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

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

Discloses that related grantee rows are cleaned up automatically, but lacks details on failure modes, permissions, or side effects. No annotations are provided, so the description carries the full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose and behavior, second provides usage guidance. No wasted words.

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

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

Given no annotations or output schema, the description covers key aspects: what it does, how it works, and why to use it. Lacks return/confirmation info but is adequate for a deletion tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by suggesting using the 'read' tool to look up IDs, which aids parameter preparation.

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

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

Clearly states the verb 'Delete', resource 'SysAdminOperation rows', and scope 'by Id' with automatic cleanup of related grantee rows. Distinguishes from siblings by specifying it is the correct tool for this entity.

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

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

Explicitly says to use this over the generic 'delete' tool because OData modifications are blocked, providing a precise when-to-use and when-not-to-use directive.

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

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

No annotations provided, so description carries full burden. Describes deletion as removing entries entirely, implying irreversibility. However, lacks details on permissions, side effects, or return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both essential: first defines action, second contrasts with sibling. No redundancy or fluff.

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

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

For a simple ID-based delete tool, coverage is high. Parameter described, usage contrasted. Lacks return value description (no output schema), but not critical for delete operations.

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

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

Single parameter 'ids' with 100% schema description coverage. The schema already explains UUID format, minItems, and lookup method; description adds no extra meaning.

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

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

Clearly states 'Delete individual grant rows by Id' to remove a grant entry entirely. Distinguishes from sibling tool `set-admin-operation-grantee` for flipping allow/deny.

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

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

Explicitly states when to use (remove entirely) and when not to (flip allow/deny, use alternative). Provides lookup method in parameter description.

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

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

Despite no annotations, the description openly discloses the tool's conditional behavior: it returns DataForge details when enabled, otherwise falls back to OData metadata. It states behaviour and inputs are identical either way, which adds transparency. It does not cover error scenarios or response format details, but the core behavior is well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence states the action and output, the second covers behavioral nuance. It is front-loaded and every word earns its place.

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

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

Given the tool has one simple parameter and no output schema, the description sufficiently covers what the tool returns (entity type, keys, properties with types/nullable) and the two source scenarios. It could mention the response format (e.g., JSON object) but the current detail is adequate for agent use.

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

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

With 100% schema description coverage, the baseline is 3. The description adds usage context ('Use this before CRUD') but does not provide additional semantic detail beyond what the schema already states about the entitySet parameter. It's adequate but not outstanding.

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

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

The description clearly states the tool inspects schema for an entity set, listing what it returns (entity type, primary keys, properties with types/nullable). It explicitly positions the tool as a pre-CRUD step, distinguishing it from the CRUD and admin sibling tools.

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

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

The description advises using the tool before CRUD operations to avoid invalid fields. It explains the two operational modes (DataForge vs OData fallback). While it doesn't list when not to use or name specific alternatives, the context is clear and helpful.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool runs server-side business processes via a specific endpoint (ProcessEngineService.svc/Execute). It also explains the process identification steps. However, it does not mention return values, side effects, permissions, or error handling, leaving gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (WORKFLOW FOR LLM, Process Identification, Parameters, etc.). Each sentence adds value. However, it is somewhat lengthy, and the example contains a contradictory use of a display name as processName, which undermines conciseness and clarity.

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

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

Without an output schema, the description should explain the return value but does not. More critically, the example uses a display name ('Lead Management Process') as the processName, directly contradicting the explicit rule that only schema names are accepted. This internal contradiction severely reduces completeness and could mislead an AI agent.

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

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

Schema coverage is 100% for both parameters. The description adds significant meaning beyond the schema: it explains the workflow for processName (display name to schema name mapping), provides common parameter patterns, GUID/date helpers, and an example. This greatly aids correct parameter construction.

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

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

The description clearly states the tool executes a Creatio CRM business process with optional parameters. It distinguishes from sibling CRUD and configuration tools by focusing on server-side process execution. The verb 'execute' and resource 'business process' are specific.

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

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

The description provides a detailed workflow for LLM on how to handle display names vs schema names, including a step to use the 'read' tool. While it doesn't explicitly state when not to use this tool, it gives strong procedural context. However, it lacks explicit exclusion criteria or comparison to alternatives.

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

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

No annotations provided, so description fully handles transparency. Clearly explains return fields and that ContactId is used for OwnerId/AuthorId, but could explicitly state the tool is read-only and has no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Though verbose, the structure is well-organized with warnings, workflow steps, use cases, and examples. Every sentence serves a purpose to enforce the mandatory first-step behavior.

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

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

No output schema, so description includes the full return format and field explanations. Covers all necessary context for a tool that provides essential user identification.

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

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

Schema has zero parameters, so description carries full burden. Adds extensive meaning by explaining the purpose, output format, and how to use the returned values.

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

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

Clearly states the tool returns current user info including ContactId, and emphasizes it as a mandatory first step for create operations, distinguishing 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.

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

Explicitly lists when to call (create activities, leads, etc.) and when not (simple queries), plus provides a step-by-step workflow and critical rules.

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

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

With no annotations provided, the description carries the full burden. It implies a read-only listing operation ('Return all...') but does not explicitly state behavioral traits such as read-only guarantee, idempotency, or any side effects. This is minimally adequate but leaves some uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary action. No filler words. Every sentence adds value: first defines the tool's purpose, second provides critical usage guidance.

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

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

For a simple listing tool with no parameters and no output schema, the description is reasonably complete. It explains what is returned (OData entity sets) and how to proceed. Lacking perhaps mention of the nature of the returned items (names/IDs), but sufficient for agent action.

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

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

The input schema has zero parameters, so the description does not need to explain parameters. Baseline for 0 params is 4, and the description adds no additional parameter semantics (none are needed).

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

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

The description clearly states the tool returns all available Creatio OData entity sets, using the specific verb 'Return' and resource 'entity sets'. It distinguishes from siblings by positioning itself as the starting point before using 'describe-entity'.

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

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

The description provides explicit workflow guidance: 'Start here, then use describe-entity to inspect fields and keys before performing CRUD.' This gives clear context on when to use this tool relative to siblings, though it does not explicitly state 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.

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

With no annotations, the description carries the full burden. It mentions the raw response structure (success flag, values map, notFoundSettings) and implies a query operation, but does not explicitly confirm read-only nature or disclose any potential side effects, auth needs, or rate limits. Good but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the action and resource, no unnecessary words or repetition.

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

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

Despite no output schema, the description adequately explains the return format (success flag, values map, notFoundSettings). For a simple tool with one required parameter, this is sufficient and complete.

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

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

Schema coverage for the single parameter is 100%. The description adds value by providing examples of valid system setting codes (e.g., 'EmailDefSendName', 'SupportEmail'), which aids the agent in understanding expected input beyond the schema.

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

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

The description clearly states the verb 'Retrieve' and the resource 'Creatio system settings', and specifies it can return values and metadata for one or more settings. It distinguishes from siblings like 'create-sys-setting' and 'set-sys-settings-value' which are write operations.

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

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

The description does not explicitly state when to use this tool versus alternatives. While context from sibling tool names implies it is for reading, no direct guidance on exclusions or prerequisites is provided.

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

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

No annotations provided, so description carries full burden. It explains read behavior, pagination, auto-lookup rewriting, response shape for count, and performance considerations. Does not explicitly state read-only nature, but it's implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points, examples, and warnings. Front-loads purpose and workflow. Slightly verbose but all content is useful. Could be more concise, but structure helps readability.

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

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

Covers all essential aspects: pagination, filtering, selecting, ordering, count-only, auto-rewriting, and related records. No output schema, but describes response shapes. Complete for a read tool.

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

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

Schema coverage is 100%, but description adds significant value: examples for filters, warnings about select/filter interaction, guidance on navigation paths, and explanation of count-only mode. Exceeds baseline.

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

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

Purpose is clearly stated as querying Creatio records with a specific workflow involving list-entities and describe-entity first. It distinguishes from siblings like list-entities and describe-entity by focusing on reading actual records with filters, pagination, etc.

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

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

Provides a clear workflow (list-entities -> describe-entity -> read) and detailed guidance on when to use count-only, pagination, and how to filter. Lacks explicit when-not-to-use, but context is strong.

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

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

With no annotations, the description bears full responsibility. It discloses that the tool invalidates the cache globally for all users and makes changes visible. It does not mention any destructive side effects or performance implications, but the core behavior is well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only three sentences, with the main action in the first sentence, usage context in the second, and parameter guidance in the third. Every sentence adds value; no wasted words.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers what the tool does, when to call it, how to parameterize it, and where to find more information.

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

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

Schema description coverage is 100% for the only parameter, featureCode, but the description adds meaningful guidance on when to pass it vs. omit it. This goes beyond the schema's description, which only states the parameter is optional and gives an example.

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

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

The description clearly states the tool invalidates the in-memory feature-toggle cache for all users, which is a specific verb-resource combination. It distinguishes from sibling tools by focusing on cache invalidation after data changes, not on directly modifying data like the other tools.

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

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

The description explicitly says to call this after changing rows in Feature or AdminUnitFeatureState via standard create/update/delete tools, providing clear usage context. It also explains how to use the optional featureCode parameter to scope the invalidation, and points to a guide for full workflow.

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

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

With no annotations, the description carries full behavioral transparency burden. It discloses the grant/revoke effect, update-on-repeat behavior, and blocked OData modifications. It does not detail side effects or confirm reversibility, but covers key behavioral traits adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the core action and add critical behavioral and usage hints. Every sentence earns its place without fluff.

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

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

Given the three required parameters with thorough schema descriptions and no output schema, the description covers functionality, idempotence, and alternative tool prohibition. It could mention the expected return (e.g., success status) but is otherwise complete for agent use.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the boolean's role as grant/revoke and the update behavior for repeat calls, which goes beyond the schema descriptions. This extra context justifies a 4.

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

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

The description clearly states the tool grants or revokes a system operation for users/roles using specific verbs and resource identifiers. It explicitly distinguishes itself from generic create/update tools by noting that OData modifications on SysAdminOperationGrantee are blocked, which helps the agent select the correct tool among siblings.

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

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

The description provides explicit when-to-use guidance: for granting or revoking system operations, and not to use generic create/update tools. It also mentions idempotent behavior for repeated calls. However, it does not explicitly state when to use the sibling delete-admin-operation-grantee for deletion, leaving a small gap.

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

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

No annotations are present, so the description bears full responsibility. It states that the tool returns a result but does not disclose whether the operation is destructive, what authentication is needed, or any side effects. The description is too vague for an update operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably short but includes redundant repetition of schema examples under 'USAGE'. The front-loading is acceptable (clear verb first), but some sentences could be combined or removed to be more concise.

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

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

Given the single nested parameter and no output schema, the description adequately explains the parameter structure with examples. However, it lacks details on return values, error handling, and behavioral aspects (e.g., idempotency), leaving gaps for a complete understanding.

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

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

Schema coverage is 100%; the input schema already includes a detailed description and examples. The description adds the same usage examples, providing minimal additional meaning. It reinforces the structure but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the action (update), resource (system settings), and scope (one or more in a single request). The verb 'update' and mention of 'system settings values' distinguish it from sibling tools like 'update-sys-setting-definition' and 'create-sys-setting', though explicit differentiation is absent.

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

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

Usage examples are provided for single, multiple, and mixed types, giving clear context. However, there is no guidance on when to use this tool versus alternatives (e.g., 'create-sys-setting' for new settings) or when not to use it. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description must carry the full burden. It states the tool is a PATCH update and gives details on partial data, but does not disclose side effects, rate limits, or what happens to omitted fields or errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but structured with sections for general use, examples, and special cases. It front-loads the main purpose but contains repetition and could be more streamlined.

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

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

The description thoroughly covers input parameters but lacks information about the output (e.g., returned object, status code) and does not mention synchronicity or error behavior. Given no output schema, this is a gap.

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

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

Schema coverage is 100%, yet the description adds substantial value by explaining data types, date formatting, common scenarios, and cross-referencing specialized guides. This goes well beyond the schema's descriptions.

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

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

The description clearly states the tool updates a record by ID using PATCH, with specific verb, resource, and method. It provides examples for Account and Contact, and distinguishes itself from create/delete siblings.

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

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

The description gives clear usage context with examples and directs to specialized prompts for dates and contact IDs. However, it does not explicitly list conditions when not to use this tool versus alternatives like create or delete.

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

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

No annotations exist, so description must disclose all behavioral traits. It mentions validation requirements and endpoint behavior but does not cover authorization, idempotency, destructive potential, or rate limits. Adequate but not complete 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, single paragraph with front-loaded purpose and key caveats. Could be slightly more structured (e.g., separate lines for important note), but every sentence adds value.

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

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

Given complexity (nested object, 2 params, many sub-properties) and no output schema, description adequately covers functionality and field semantics. Lacks details on return values, error scenarios, or how updates affect existing setting instances; minimal for full completeness.

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

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

Input schema has 100% description coverage for all properties. Description adds value by explaining the required fields constraint on update and conditional requirement for referenceSchemaUId only when valueTypeName='Lookup', surpassing schema details.

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

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

The description clearly states the tool updates system setting definition metadata, listing specific fields (name, description, valueTypeName, cache flags, etc.). It distinguishes from siblings like 'create-sys-setting' and 'set-sys-settings-value' by focusing on definition modification.

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

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

Provides important usage guidance: Creatio always requires Code, Name, and valueTypeName on update, even if unchanged. References /sys-settings-guide for value types and lookup tips. Does not explicitly mention when not to use or alternatives among siblings.

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

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

With no annotations, the description carries full burden. It discloses the upsert behavior, that modifications are blocked via generic tools, and that response contains the operation Id. It does not cover permissions or rate limits, but for this tool's nature it is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence for the main action, one for sibling distinction, one for response and reference. Every sentence adds value with no redundancy.

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

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

For a tool with 4 parameters, no output schema, and moderate complexity, the description covers the essential context: response contains operation Id, references a guide, and explains blocking of generic tools. No gaps.

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

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

The input schema already describes all 4 parameters with 100% coverage, including the id parameter's role. The description adds value by framing the create/update logic (omit vs. supply id), reinforcing the schema's guidance.

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

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

The description clearly states it creates or updates a SysAdminOperation, with explicit conditions: omit id for create, supply id for update. It specifies the resource and distinguishes from generic create/update tools.

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

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

The description explicitly says to use this tool instead of generic create/update tools because OData modifications are blocked. It also notes reads go through the standard read tool, providing clear when-to-use and when-not-to-use guidance.

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