Cronitor MCP by usefulapi

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

Annotations supply only destructiveHint=true, so the description carries most of the burden and does add real value: 'additive', the POST /monitors endpoint, and the partial-payload semantics. It never reconciles the odd destructiveHint on a create operation, nor mentions auth requirements or what happens on duplicate keys.

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 fragments with no filler; the core action leads. The 'Cronitor API: POST /monitors' line is mildly redundant with 'Creates a monitor' but is fast to scan and costs little.

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?

This is a 9-parameter, nested-object mutation tool with no output schema, yet the description says nothing about required fields (key, type), the response shape, or error behavior such as duplicate keys. With no output schema, return-value guidance is expected and absent, leaving the definition thin for its complexity.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents all nine properties including the enum and nested request object. The description adds one useful nuance — that omitted fields are simply not sent rather than defaulted — but no syntax or interaction detail beyond that.

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 ('Creates a monitor in Cronitor') plus the underlying API call, so an agent knows exactly what the tool does. It does not explicitly distinguish itself from siblings like cronitor_update_monitor or cronitor_delete_monitor, relying on the name alone for that routing.

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?

No when-to-use guidance at all: nothing says when to prefer create over update, that the 'key' must be unique, or what prerequisites (auth, existing monitor collision) apply. Only a behavioral aside ('Sends only the fields you provide') is offered, which is not usage guidance.

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

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

Annotations already declare destructiveHint=true, so the bar is lower, but the description adds meaningful context: the deletion is PERMANENT and irreversible, and it names the underlying API operation. It stops short of describing failure modes (e.g. missing key) or side effects on dependent checks.

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: the destructive warning and the resource come first, followed by the API mapping. Every sentence earns its place with no filler.

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 delete tool with annotations covering the destructive profile and no output schema, this is nearly complete. Only the absence of usage context/alternatives and any error behavior keeps it from being fully sufficient.

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 'key' parameter, so the schema already documents it fully. The description only echoes the identifier in the API path template and adds no new semantics, which matches the baseline 3 when the schema does the heavy lifting.

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 — 'PERMANENTLY deletes a monitor from Cronitor' — which is unambiguous against the create/get/list/update/ping siblings. The added API path (DELETE /monitors/{key}) reinforces the exact operation.

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 says nothing about when to use this versus alternatives such as cronitor_update_monitor or deactivating a monitor, nor any prerequisites. 'Destructive and irreversible' is a warning, not usage guidance, so the agent must infer the context itself.

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 readOnlyHint=true already declaring the safety profile and no output schema present, the description usefully discloses the shape of what comes back (latest event, latest invocations, passing status). It stops short of mentioning auth, rate limits, or error behavior, but it carries the return-value burden reasonably well.

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 tight sentences: the purpose and payload come first, the mental model second, and the API endpoint last. Nothing is wasted and nothing important is buried.

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 single-resource fetch with no output schema, the description covers the essentials including the returned fields. Slightly incomplete only on error/not-found behavior and whether the status is computed live versus cached.

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 'key' parameter, so the schema already documents it fully; the description adds no format or acquisition guidance (e.g. where to get the key). Baseline 3 is appropriate when the schema does the work.

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 detail for one monitor') and enumerates the key payload contents (latest_event, latest_invocations, passing status), which cleanly separates it from cronitor_list_monitors and the mutation 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 framing 'is X healthy right now?' gives a clear situational context for when to reach for this tool, but it never names the alternatives (e.g. use cronitor_list_monitors for a roll-up) or any exclusions, so routing still requires 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?

readOnlyHint=true already declares the safety profile, so the bar is lower. The description adds useful context — that results are paginated and include pass/fail status — but says nothing about rate limits, default page size, or ordering.

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 tight sentences: purpose first, API mechanics second. No filler, nothing redundant.

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 paginated read-only list with full schema coverage and annotations covering safety, the description is nearly sufficient. It correctly tells the agent what each entry contains; only the absence of an output schema leaves the exact response shape 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 both parameters are already documented in the schema (page is 1-based, default 1; pageSize). The description merely restates that pagination uses page + pageSize, adding no new semantics.

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 ('List monitors') and adds the distinguishing payload ('current passing/failing status'), making it clearly distinct from cronitor_get_monitor (singular) and the create/delete/update/ping 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?

No guidance on when to use this over cronitor_get_monitor or how to iterate pages. The pagination mention is mechanical (endpoint/params) rather than contextual advice about when listing is appropriate.

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?

Only destructiveHint=true is provided, so the description must carry behavioral weight — and it does add real context beyond the annotation: that this 'can clear or trigger alerts' and that pings hit a specific telemetry endpoint. It stops short of explaining the effect of individual states (e.g. that 'pause' halts monitoring) or auth needs.

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 compact sentences that front-load purpose, then behavior, then the endpoint template. Slightly dense but every clause (states, alert side-effects, URL shape) 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?

With 6 parameters, no output schema, and only a destructiveHint annotation, the description covers purpose but omits per-state semantics (what 'pause'/'fail' do to alert state) and any auth/URL-key requirement. Adequate to invoke, but thin for a state-driven alerting mutation.

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 every parameter including host, metric, series, and message is already documented. The description only restates the state enum and the state= query fragment, adding no syntax or format meaning beyond the schema — the 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?

States a specific verb and resource ('Reports a telemetry event ... for a monitor'), enumerates the exact state values, and the telemetry-ping role is clearly distinct from the CRUD siblings (create/get/list/update/delete_monitor). An agent can select this over any sibling without opening the 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?

Usage is implied by 'records job/heartbeat activity' and the state list, but it never states when to choose this over cronitor_update_monitor or that it is the only tool for reporting runtime events. No explicit when-not or alternative routing is given.

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 only supply destructiveHint=true; the description adds genuine behavioral context beyond that by disclosing the PUT/upsert model and the partial-update contract ('sends only the fields you provide'). It stops short of warning that list-valued fields like tags/notify/assertions are replaced wholesale, which is relevant given the destructive hint.

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 tight sentences with no padding: the upsert behavior is front-loaded, followed by a concrete usage example and the API/partial-update contract. Every clause carries information the agent can act on.

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 10-parameter, nested-object mutation tool with a single required key, the description covers the essential upsert and partial-update semantics (no output schema means return values need not be explained). The remaining gap is the absence of any mention of how array fields are handled on update.

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 all 10 parameters including examples for schedule and paused. The description repeats the paused:true and schedule examples but adds no syntax or format detail beyond what the schema provides, so 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?

States a specific verb+resource (create/update a monitor by key) and captures the upsert nature via PUT semantics, which is meaningful because the key is required. It does not, however, differentiate itself from the sibling cronitor_create_monitor, leaving the agent to infer whether create should route here or there.

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 is implied through examples ('change schedule', 'pause via paused:true') but there is no explicit when-to-use or when-not guidance relative to cronitor_create_monitor or cronitor_get_monitor. The agent must infer the upsert-vs-create distinction on its own.

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