cronofy

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

Annotations already provide destructiveHint=true, and the description reinforces destructive behavior with the explicit word 'Destructive' and adds context that it affects a 'real connected calendar.' It also provides the exact HTTP DELETE API endpoint, giving useful behavioral detail beyond the annotation.

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

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

The description is a single, focused sentence that front-loads the action and key qualifier, then states destructiveness and the API endpoint. There is no filler or redundant material.

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

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

For a two-parameter destructive delete operation with full schema coverage and a destructiveHint annotation, the description provides the necessary behavioral warning and API path. No critical information needed to invoke the tool correctly is missing.

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 both calendar_id and event_id are already documented. The description adds 'by your event_id' and places the event_id in the JSON body, but this largely restates information already present in the schema rather than adding substantial new 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?

Description uses a specific verb and resource: 'Deletes an event (by your event_id) from a real connected calendar.' It clearly identifies the action, the target, and an important qualifier ('real connected calendar'), and it is distinct from sibling tools like cronofy_read_events and cronofy_upsert_event.

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

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

The description implies usage for deleting a specific event, but it does not explicitly state when to use this tool versus alternatives such as cronofy_upsert_event for creating or updating events. There is no when-not-to-use guidance or mention of sibling tools.

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?

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it targets the authenticated account and lists the fields returned, which is useful but does not go beyond that. It does not mention authentication requirements, rate limits, or response format, though the annotations lower the 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?

The description is a single focused sentence that names the operation, the target, the key returned fields, and the API endpoint. There is no filler or redundancy, and the most important information appears immediately.

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 zero-parameter, read-only account metadata lookup, the description is nearly complete: it identifies the resource, the fields returned, and the REST endpoint. It lacks output schema details and error/edge-case information, but the simplicity of the tool and the readOnlyHint annotation make this a minor 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?

The tool has zero parameters, so the baseline is 4. The description correctly implies no inputs are needed and focuses on the output fields. There is no parameter detail required beyond what the empty schema already communicates.

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 ('Get'), resource ('authenticated Cronofy account's details'), and enumerates the returned fields (id, email, name, default tzid, locale). It is clear and distinct from siblings in practice, though it does not explicitly contrast itself with cronofy_get_userinfo, which could be confused without deeper inspection.

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 no guidance on when to use this tool versus the siblings such as cronofy_get_userinfo, cronofy_list_profiles, or cronofy_list_calendars. It only states what the tool does and the API endpoint, leaving the agent to infer usage from the tool name.

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?

Annotations already declare readOnlyHint=true, and the description aligns with that by saying 'Read' and referencing GET. It adds useful behavioral context beyond annotations: the return shape '{ pages, free_busy }' and the account-wide calendar scope.

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 with no filler. The core action is front-loaded, followed by the return shape and API method, making it easy for an agent to parse quickly.

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 read-only tool with 5 fully described parameters and no output schema, the description gives the essential return envelope and scope. However, it does not clarify default window behavior when from/to are omitted, which could matter since only tzid is required.

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 baseline is 3. The description's phrase 'over a time window' and 'across the account's calendars' conceptually maps to from/to and calendar_ids, but it does not add parameter-level detail beyond what the schema already provides.

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: 'Read free/busy information across the account's calendars over a time window.' This clearly distinguishes it from sibling tools like cronofy_read_events or cronofy_list_calendars because it targets availability data, not event details or calendar metadata.

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 clear context: this is for free/busy availability across account calendars within a time window. It does not explicitly name alternatives or state when not to use it, but the scope is sufficiently clear that an agent can infer the appropriate situation.

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?

The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context by specifying the OpenID-style profile scope and the GET endpoint. It does not contradict the annotation and gives the agent a clear sense of what kind of data is returned.

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

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

The description is a single sentence that states the resource, key fields, and API endpoint with no filler. Every part earns its place and 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.

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

For a parameterless GET operation with a readOnlyHint, the description is complete: it identifies the resource, names the expected fields, and gives the endpoint. No output schema exists, but the description provides enough detail for an agent to understand what the tool returns.

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 has zero parameters, so there is no parameter ambiguity to resolve. The description correctly focuses on the return resource rather than inputs, matching the baseline expected for a parameterless tool.

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 names a specific verb (Get), a clear resource (OpenID-style profile of the authenticated user), and key fields (sub, email). It also includes the exact API endpoint, which removes ambiguity and helps distinguish it from sibling tools like list_profiles.

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 what the tool does but gives no guidance about when to use it instead of related siblings such as cronofy_get_account or cronofy_list_profiles. An agent is left to infer the appropriate use case from the resource name alone.

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?

Annotations already declare readOnlyHint=true, so the description does not need to repeat safety. It does add useful context by stating the scope 'all calendars the authenticated account can see' and the HTTP endpoint GET /v1/calendars. However, it does not disclose pagination, ordering, or potential error behavior, which keeps this at a solid but not exceptional level.

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 short sentences with no filler. The primary purpose and scope are front-loaded, and the API endpoint is a useful one-line addition. Every part 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?

For a parameterless read-only listing tool with annotations covering the safety profile, this is complete. The description names the key output fields even though there is no output schema, and the sibling context is clear enough that an agent can correctly invoke it.

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 has zero parameters, so the input schema is fully complete (100% coverage) and there is nothing for the description to add. The 0-parameter baseline of 4 applies, and the description appropriately focuses on the result rather than parameters.

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 'List' and the resource 'all calendars the authenticated account can see', and enumerates the returned fields (id, name, profile, readonly, primary). This distinguishes it from sibling tools like list_profiles and read_events by explicitly naming the calendar 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?

The description provides no explicit guidance about when to use this tool versus alternatives such as cronofy_list_profiles or cronofy_read_events. While the purpose is clear, there is no when-to-use or when-not-to-use context, and no mention of alternative selection criteria.

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?

Annotations already declare readOnlyHint=true, and the description reinforces this with 'List' and 'GET /v1/profiles'. It adds the endpoint detail and confirms this is a read-only operation, but provides no further behavioral context such as pagination, output shape, or authorization requirements. Given the existing annotation, this is adequate but not rich.

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

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

Two short sentences, one describing the operation and one giving the exact API endpoint. Every word adds value, and the core purpose is front-loaded in the first sentence.

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, zero-parameter list operation, the description is complete enough to call the tool correctly. It does not describe the return payload, but the absence of an output schema and the low complexity make this a minor gap rather than a significant omission.

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 has zero parameters, so no parameter documentation is needed. The description adds no parameter-related meaning, but the baseline of 4 applies because there is nothing for the schema or description to explain.

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

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

States a specific verb ('List') and resource ('connected calendar accounts/profiles linked to this Cronofy account') with concrete examples. It also names the API endpoint, and clearly distinguishes this from sibling cronofy_list_calendars by focusing on accounts/profiles rather than calendars.

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 context: use this when you need the connected calendar accounts/profiles for the Cronofy account. It does not explicitly mention when not to use it or name alternatives, but the resource distinction from sibling tools is clear enough for basic selection.

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

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

The readOnlyHint annotation already covers the safe-read behavior, so the description is not required to restate that. It adds the return shape ({ pages, events }) and the REST endpoint, which is useful, but it does not disclose pagination behavior or how filtering options affect results beyond what the schema already says.

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

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

Two sentences with no filler: the first states the operation and scope, the second gives the return value and API endpoint. Information 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?

For a tool with eight parameters and no output schema, the description is adequate but leaves gaps. It gives the return shape and endpoint, but offers no guidance on when to use filters like include_deleted, only_managed, or last_modified, and only hints at pagination through the 'pages' key.

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 eight parameters are already documented. The description only adds a high-level connection between the time window and the from/to parameters, providing minimal additional value 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 'Read' and the resource 'events', and adds scope by mentioning the account's calendars and a time window. This distinguishes it from sibling tools like cronofy_delete_event or cronofy_list_calendars, though it does not explicitly name any alternatives.

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 context is implied through phrases like 'across the account's calendars over a time window', which tells an agent this is the tool for reading event data. However, there is no explicit guidance about when to prefer this over related siblings like cronofy_get_free_busy or cronofy_upsert_event.

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?

Annotations already declare destructiveHint=true, and the description adds valuable context by emphasizing this writes to the REAL connected calendar and affects the user's actual data. It also discloses the upsert-by-event_id behavior, which is meaningful beyond the annotation alone.

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 compact: two clear sentences plus the endpoint. It front-loads the core action and side-effect warning without redundant phrasing or unnecessary 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?

Given the complete schema coverage and the destructiveHint annotation, the description provides sufficient context for invoking the tool. It lacks explicit guidance on update behavior for omitted optional fields and does not describe the response, but these are minor for basic invocation.

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 input schema fully documents all parameters. The tool description adds little parameter meaning beyond noting the upsert keyed by event_id and the endpoint, but that doesn't elevate above the baseline.

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

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

The description clearly states the tool creates or updates an event via upsert by event_id, identifying the exact resource and action. It also names the API endpoint and distinguishes itself from siblings like cronofy_delete_event and cronofy_read_events.

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

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

The description makes the use case clear: create or update a real connected calendar event using event_id for upsert semantics. It does not explicitly contrast with sibling tools, but the operation is self-evident and the 'writes to the user's actual calendar' warning sets appropriate expectations.

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