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

No annotations are provided, so the description carries the full burden. It does disclose that the call returns the created system details and that the operation creates a new entity, but it omits permissions/authentication requirements, error or duplicate-title behavior, and whether the system is created in a draft or active state.

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

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

Three short sentences with zero filler: what it does, what it returns, and where to go for more. The scope statement and the alternative routing are both front-loaded and easy to scan.

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

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

For a single-parameter create tool with no annotations and no output schema, the description covers purpose, return value, and sibling routing adequately. It stops short of behavioral caveats (auth, validation, side effects) that would make it fully self-sufficient without annotations.

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?

Only one parameter exists and schema description coverage is 100%, so the schema fully documents 'title'. The description's phrase 'with a given title' adds no format, constraint, or uniqueness semantics beyond the schema, making the baseline 3 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?

States a specific verb and resource ('Create a new data system') and immediately distinguishes itself from the sibling 'create_system_advanced' by scope of details. An agent can tell this apart from the other create/list/get siblings without opening any schema.

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 names the alternative ('create_system_advanced') and the condition that selects it ('For adding extended details (owner, hosting, processors, etc.)'). It lacks an explicit inverse statement of when this basic variant is preferred, but the routing intent is clear.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior for a mutation tool: upsert-by-title semantics and that unprovided fields remain unchanged on existing systems. It omits permissions/auth requirements, whether it returns the resulting object, and any rate limits or side effects, leaving notable 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?

Front-loaded with the verb and resource, and only three sentences with no filler. The second and third sentences overlap on update behavior and could be merged, but nothing is wasteful.

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 nine-parameter mutation tool with no annotations and no output schema, the description covers the key upsert/merge semantics but says nothing about return values, required permissions, or differentiation from the sibling create_system. Adequate but with clear 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?

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description's note about title being the matching identifier duplicates the schema's own wording and adds no new syntax or format meaning beyond it.

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

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

States a specific verb+resource (create or update a data system) and qualifies it with 'extended details', making the tool's scope clear. However, it never explicitly distinguishes itself from the sibling create_system or explains what 'extended' means relative to it, so an agent must infer the difference.

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 explains matching behavior ('If a system with the given title already exists, it will be updated') but gives no guidance on when to choose this tool over the sibling create_system or update paths. Choosing between the advanced and basic create variants is left entirely to inference.

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 at all, the description carries the full burden, and it delivers useful behavioral detail: it returns all available fields with human-readable names and omits empty fields. What it omits is failure behavior (e.g., what happens for an unknown ID) and any permission requirements, so it is strong 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?

Four tight sentences with zero filler: identity/purpose first, then return shape, then the routing hint. Each sentence contributes distinct information.

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

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

There is no output schema and no annotations, so the description must stand in for both, and it does so by describing the returned fields and the empty-field omission rule. It stops short of covering error/not-found behavior or authorization needs, which is the only meaningful gap for a single-record read.

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 single parameter (system_id with its own description), so the schema already documents the input fully. The description's 'by its ID' framing adds no syntax or format detail beyond that, matching the baseline 3 for high-coverage schemas.

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

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

States a specific verb and resource ('Get full details of a specific data system by its ID'), and the singular scope plus ID-based lookup distinguishes it from the list/search siblings. An agent can tell immediately this is the single-record fetch rather than a query tool.

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 names the alternatives ('list_systems' or 'search_systems') and the condition that selects them ('first to find system IDs'), establishing the correct lookup-then-fetch workflow. Nothing about when to reach for the siblings is left to inference.

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 disclosure burden. It usefully characterizes the result as a 'compact overview' and lists the fields returned, but says nothing about read-only safety, permission requirements, or pagination behavior beyond naming the parameters.

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

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

Four short sentences, front-loaded with the core action, then the return nature, then the sibling alternative, then pagination. No filler 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?

For a simple two-parameter read tool with no output schema, the description sufficiently covers what is returned and how to drill into a single record. Nothing about response shape or limits is missing, though the absence of annotations leaves behavioral guarantees implicit.

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

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

Schema description coverage is 100%, so the schema already documents limit and offset, including the default of 20 and offset semantics. The description adds only a restatement that pagination is supported, which is minimal value over the schema; baseline 3 applies.

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

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

The description states a specific verb and resource ('List data systems registered in Cyberday') and immediately differentiates itself from 'get_system' by contrasting compact overview vs. full details. An agent can distinguish this from siblings like search_systems or systems_summary without opening any schema.

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?

It explicitly says to use 'get_system' with a specific ID for full detail, giving a clear when-to-use-this-vs-that condition. It does not address when to prefer 'search_systems' or 'systems_summary', so the routing guidance is clear but incomplete across the sibling set.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that results are compact, that filters combine with AND, and that text matching is case-insensitive, but it is silent on pagination beyond the raw limit parameter, on permissions/auth needs, and on ordering or total-count 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?

Front-loads the core purpose and the get_system pointer in the first two sentences, then moves to filter semantics. The trailing list of localized status examples is longer than strictly necessary, but every sentence maps to a real behavioral detail.

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 exists, and the description compensates by stating that results are compact with key fields and directing the agent to get_system for full detail. Combined with full schema coverage of all five optional parameters, this is close to complete, with the main remaining gap being result ordering and pagination semantics.

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

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

Schema description coverage is 100%, so the schema already documents every parameter; the baseline is 3. The description adds genuine semantics that the schema lacks (AND combination across filters, case-insensitive text matching), but also names 'hosting type' as a filter when no such parameter exists, introducing mild noise rather than added clarity.

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

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

States a specific verb (search and filter) plus the resource (data systems) and enumerates the filterable fields, which is far more than a restated name. It differentiates from get_system explicitly ('Use get_system for full details'), but does not distinguish itself from sibling list_systems or systems_summary, so an agent cannot fully route between the three list-like tools on the description alone.

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?

Gives a clear context — multi-criteria filtering with AND logic — and names the alternative tool for full-record retrieval. It stops short of stating when to prefer this over list_systems or systems_summary, and gives no guidance on the limit parameter or when to request all results.

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 disclosure burden and does a fair job: it enumerates what the response contains (total count, status breakdown, overdue reviews, framework coverage, CIA importance distribution), which tells the agent this is a read-only aggregate. It does not explicitly confirm read-only/non-destructive behavior or clarify edge cases like an empty system list.

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

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

Three short, front-loaded sentences: purpose, return contents, recommended use. Efficient overall, though 'high-level overview' and 'best starting point to understand the current state' are mildly redundant in intent.

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?

There is no output schema, so the description appropriately compensates by listing the return fields, and with zero parameters there is nothing else an agent needs to invoke it. A brief note on whether results are scoped to a tenant or affected by filters would make it fully complete.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is needed, consistent with the empty input 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?

Names a specific verb ('Get') and resource ('all data systems in Cyberday') and frames itself as an aggregate summary rather than a list, which implicitly separates it from list_systems and search_systems. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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?

'This is the best starting point to understand the current state of your data systems' gives a clear positive use case. However, it offers no when-not guidance or explicit routing away from siblings like list_systems or search_systems when the agent needs individual records rather than aggregates.

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