INITE

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

Annotations declare non-read-only, non-destructive, non-idempotent, non-open-world, but say nothing about what actually happens. The description fills that in: a calendar invite is sent to the person's own email, a booking_key comes back as the handle for later move/cancel, and the commercial terms (free, no deposit, no cancellation or no-show fee, max 3 moves, cancel anytime before start) are spelled out. That is concrete consequence-level disclosure well beyond the annotations.

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 action, then prerequisites, then downstream handle, then terms — a sensible order with no filler. The sentence "The answer's booking_key moves (inite_move_call) or cancels (inite_cancel_call) it" is grammatically awkward and takes a second read, which is the only drag on an otherwise tight definition.

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 an 8-parameter mutation tool, the description covers the two things that matter and are not in structured form: the consent/ownership precondition and the refund/cancel policy that an agent may need to relay. An output schema exists, so return values need no explanation, and the one return detail that matters (booking_key) is still called out.

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 already 100%, so the baseline is 3, and the description does add cross-tool meaning: starts_at is not any ISO instant but one drawn from inite_slots, and topic is a service id from inite_services defaulting to diagnostic. It also constrains email semantically (the person's own, where the confirmation and invite land). Some of this restates the schema wording, which caps it at 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 opening sentence names a specific verb and resource ("Book a call with the INITE team") and immediately scopes it with consent and the person's own email. Nothing in the sibling list (inite_cancel_call, inite_move_call, inite_slots, inite_services) could be confused for this, because the description explicitly assigns those jobs elsewhere.

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 pinned to prerequisites: starts_at must come from inite_slots, topic from inite_services, and the resulting booking_key routes to inite_move_call or inite_cancel_call. That is strong routing guidance. It stops short of an explicit when-not-to-book exclusion beyond the consent clause, which keeps it at 4 rather than 5.

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 idempotentHint=true, so the safety profile is covered. The description adds two things the annotations cannot: the action is free of charge and it triggers an email notification to the person, which is exactly the kind of user-visible side effect an agent needs before invoking.

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 clauses with zero filler; the action and the precondition are front-loaded before the cost and side-effect note. Nothing could be removed without losing meaning.

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 one-param destructive tool with rich annotations and an output schema, the description covers the consent precondition, cost, and user notification. Only the absence of explicit sibling routing keeps it from being 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?

There is a single parameter with 100% schema description coverage ('inite_book_call's booking_key'), so the schema already does the work. The description adds no format, sourcing, or lookup guidance beyond that, 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?

The description leads with a specific verb and resource ('Cancel a booked call'), which cleanly separates it from inite_move_call and inite_book_call among the siblings. It does not name those alternatives, but the verb alone is 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?

Adds a real gating condition: 'only when the person asked,' which tells the agent not to cancel proactively. It stops short of naming alternatives for related intents (e.g., rescheduling via inite_move_call), so it is clear context without explicit routing.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the tool returns connection artifacts rather than mutating anything, but discloses nothing further about behavior, prerequisites, or failure modes; with an output schema present, the return-value detail is largely redundant.

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 compact sentences: purpose and trigger first, then the three argument modes, then what comes back. No filler, and the alternative-path information is front-loaded before the parameter recap.

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-required-parameter lookup with full schema coverage, an output schema and complete safety annotations, the description covers the essential unknown (default behavior with no argument) plus the intent trigger. Missing only guidance on what to do if the returned connection information fails or when it should be re-invoked.

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 the baseline is 3, but the description adds genuinely new meaning: the zero-argument default ('the server beside this one'), which the schema does not state at all. It also glosses `for` as 'the one that does a job' and `all: true` as 'every server,' reinforcing rather than duplicating the enum documentation.

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 action (add another INITE MCP server to this client) and frames it as retrieving connection info rather than performing the connection, which the closing sentence about returning a URL, Claude Code command and custom-connector step makes concrete. It is distinguishable from the atlas_*/match_* siblings, though it never names an alternative connector-related 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?

It gives an explicit trigger: use it 'when the person wants something this one does not do,' which is a clear when-to-use condition. It also explains usage of each argument mode (no argument, `for`, `all: true`), but offers no when-not-to-use guidance or named 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?

Annotations already declare this is a non-read-only, non-idempotent, closed-world write with no destructive effect. The description adds the fact that the reply goes to the person's email, which is real behavioral context, but it says nothing about confirmations, rate limits, or whether repeated sends create duplicate messages.

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, front-loaded with the action and followed by the alternative. Every clause earns its place and nothing is repeated.

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 an output schema present and full parameter documentation, the description only needs to establish purpose and routing, which it does. It could be slightly stronger by saying what the caller receives back or confirming the message reaches the team rather than only the reply path.

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%, including the language enum's effect on currency and copy and the service enum values, so the schema carries the parameter load. The description's email mention duplicates the email property's own description rather than adding 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?

States a specific verb and resource ('Send a message to the INITE team') plus the delivery outcome ('the reply goes to their email'), so the agent knows exactly what action occurs. It also names the sibling inite_book_call, so it cannot be confused with the adjacent 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?

Gives an explicit routing rule: for a question that needs a conversation, use inite_book_call instead. The positive case (send a message) is implied by the description, but there is no guidance on when a message is inappropriate versus, say, inite_connect or inite_services.

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 declare readOnlyHint=false and idempotentHint=false, so the agent knows this is a non-read, non-idempotent action. The description adds genuinely useful context beyond that: the payload is a PDF of a few pages, delivery is by email to a named person, and consent is a prerequisite — a policy constraint the annotations cannot express.

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?

It is short and the send/consent condition is front-loaded in the second sentence. However, the first sentence is a comma-spliced fragment that spends words describing PDFs rather than stating what the tool returns, which hurts rather than helps 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?

With zero required parameters, a full schema, and an output schema covering return values, most of the burden is already met elsewhere. The remaining gap is the ambiguity of dual behavior — whether a no-argument call lists guides and whether slug without email is an error — but the essentials for calling it correctly are present.

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 slug, email, and lang are already documented, including the lang-driven currency/copy behavior. The description ties slug and email together as the send trigger, which is modest added meaning, but says nothing about lang or what happens when slug is given without email. 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 does say the resource is INITE's PDF guides and implies two modes: browsing (titles, coverage, page) and emailing one. But the verb for the browse mode is never stated explicitly, and the opening clause is a fragment ("titles, what each covers, its page"), so an agent must infer that calling without slug/email lists guides. It also does not distinguish this tool from siblings such as inite_services.

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 gives an invocation condition ("Pass slug and email to send one") and an important constraint ("only with their consent"), which is real usage guidance. It does not say when to use the listing mode versus the send mode, nor when to prefer this over sibling tools like inite_services or inite_contact.

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 a non-read-only, idempotent, non-destructive, closed-world mutation, so the safety profile is covered. The description adds two things annotations cannot convey: consent must be obtained, and an updated invite is sent to the attendee as a side effect. It stops short of saying whether the original invite is rescinded or how failures surface.

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, zero filler, with the core action and its constraint front-loaded. Nothing could be removed without losing 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?

An output schema exists, so return values need no explanation, and the tool is a simple two-parameter mutation whose inputs are fully documented. What remains missing is modest: failure behavior when the slot is taken and whether the prior booking is replaced atomically.

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 structured form, and the description only echoes that starts_at comes from inite_slots. booking_key is not mentioned at all beyond the schema, so the description adds little beyond 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 gives a specific verb and resource ("Move a booked call") plus the source of the new time ("from inite_slots"), which implicitly separates it from inite_book_call and inite_cancel_call. It never names those siblings explicitly, so the differentiation is inferred 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?

"with the person's consent" is a real precondition and "from inite_slots" hints that availability must be fetched first, but the description never states when to move versus cancel-and-rebook, nor what to do if the requested time is unavailable. Usage is implied rather than spelled out.

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 readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: language drives currency (pt quotes reais), what each step's full record includes (delivery, duration, price kind, refund, how it starts), and how a step connects to `inite_book_call`. It stops short of mentioning caching or ordering guarantees beyond 'cheapest first'.

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?

One compact sentence pair with the core purpose front-loaded and mode selection following. The dense backtick-heavy phrasing packs a lot into few words, though the second clause runs long and could be broken for 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?

With an output schema present, the description only needs to explain purpose, modes and defaults — all of which it does. All three optional parameters are accounted for, and the cross-reference to inite_book_call closes the loop on next steps.

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 the baseline is 3; the description earns more by tying parameters to each other — `slug` must be an id the summary returns, and `lang` changes both currency and copy, with en as the default. That relational meaning is not spelled out in 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 gives a concrete verb and resource — INITE's services as a ladder, cheapest first — plus exactly what each step contains (id, name, price, one line). It also separates the three modes (default summary, `slug`, `full: true`), so an agent can tell it apart from siblings like inite_book_call or inite_guides without reading 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?

It clearly states when to use each mode: bare call for the summary, `slug` for one step in full, `full: true` for all of them. It also points at the sibling `inite_book_call` as how a step starts. It doesn't explicitly say when NOT to reach for this tool versus inite_guides, but the context is unambiguous.

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, idempotentHint, non-destructive, and a closed-world scope, so the safety profile is covered. The description adds some context about returned value shape (ISO instants plus call length and host zone), but says nothing about pagination behavior, maximum window, or the possibility of an empty result set — and with an output schema present, return-format detail carries less weight.

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 the resource scope front-loaded and the actionable instruction second — nothing is padded. The first sentence is syntactically awkward, which costs a point but not usability.

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 three-param read tool with full annotation coverage and an output schema, the description covers what the tool returns and the immediate next step. The remaining gap is pagination mechanics (offset/nextOffset flow), which the schema hints at but the description never confirms.

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 limit, offset, and time_zone are already documented, and the description adds no parameter detail — baseline 3 applies. The one friction point is that the description says results come with "the host's time zone" while a time_zone parameter lets the caller pick the display zone, leaving the relationship between the two unstated.

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 the specific resource (free call times on INITE's calendar) and the output form (ISO instants, with call length and host time zone), which is enough to distinguish it from inite_book_call. The phrasing of the opening clause ("The call times INITE's calendar has free") is garbled and never uses an explicit verb like "list", so it falls short of a clean 5.

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 gives an explicit downstream handoff: "Pass one of them to inite_book_call as starts_at," which tells the agent exactly how this tool fits into a booking flow. It does not state any when-not conditions, prerequisites, or filtering behavior, so it stops short of full routing guidance.

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