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

Annotations already flag destructiveHint=true and non-idempotent; the description goes further by disclosing that update replaces the contacts list wholesale and that delete requires confirm: true, plus the date-defaults-to-today behavior. No contradiction with the write/destructive annotation profile.

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 front-loaded definition sentence followed by a tight per-action bullet list; no filler and every clause carries routing or semantic 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?

For a 10-param multi-action mutation tool with no output schema, the description covers each action's required fields and the key mutation semantics. It stops short of explaining pagination/limit behavior on list or failure modes, but nothing essential for correct invocation 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 coverage is only 40%, so the description must compensate and largely does: it defines summary, date (defaults today), type with concrete examples and a pointer to monica_reference kind=activity_types, contacts ('who it was with', replaced on update), and confirm. Only id and limit semantics are left entirely to 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?

States a concrete resource (activities: things done together with contacts) and enumerates all five verbs (list/get/create/update/delete) with the scope of each. An agent can tell this apart from monica_journal, monica_notes, or monica_calls purely from the description 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?

Each action is scoped with its own condition: 'list — a contact's activities, or the most recent across everyone', 'delete — confirm: true', 'update — change any of it'. This is clear intra-tool routing, but it never names when to pick a sibling tool (e.g. journal vs activities) or states exclusions.

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 readOnlyHint=false, so the safety profile is known. The description adds genuinely useful behavioral context beyond that: the delete-confirm requirement ('confirm: true') and the date default ('today by default'). It stops short of describing what deletion affects or permission 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?

A single front-loaded sentence followed by tight per-action bullets; no filler, and the action-to-behavior mapping is scannable.

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 no output schema and seven parameters, the description covers the action surface and the confirm gate but omits what list returns and the semantics of contact/content/limit. Adequate minimum for a CRUD tool 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 coverage is only 43%, so the description must compensate. It does clarify the date default, the confirm requirement for delete, and that id-based ops apply to update/delete, but leaves contact, content, and limit undocumented in both schema and description.

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 concrete resource ('Phone calls with contacts') and enumerates all four operations (list, create, update, delete), so the agent knows exactly what the tool does. It does not, however, explicitly distinguish itself from siblings like monica_conversations or monica_activities, so sibling routing is left to inference.

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?

Per-action conditions are given: list returns a contact's calls or recent across everyone, create logs a call with date defaulting to today, update/delete go by id and delete needs confirm:true. However, there is no guidance on when to choose this tool over the many sibling tools (e.g., conversations/activities), so alternative selection is implied rather than stated.

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=false, but the description adds real behavioral detail: removes on fields/addresses require confirm:true, and adding tags by name silently creates new tags as a side effect. That is useful mutation context beyond the structured hints, though it doesn't cover auth/permission 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?

The description is dense but front-loaded and organized around the action matrix, so each clause earns its place given 14 parameters and four operations. It is longer than ideal but avoids 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 14-parameter, destructive, no-output-schema tool, the operation-by-operation coverage is strong, and the 'list' bullet effectively conveys what is returned. The one notable omission is how the target contact is identified, which an agent needs before calling.

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 only 14%, so the description must carry the load, and it largely does — it explains action values, kind (field/address/tag), type-by-name, value, id, tags-by-name, and the confirm flag. Gaps remain: the required 'contact' identifier and the individual address fields (street/city/province/country/postal_code) are never explained, though their names are largely self-evident.

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 names the resource (a contact's fields, postal addresses, and tags) and the action matrix makes clear this is a CRUD tool over those sub-resources. It is specific but doesn't explicitly distinguish itself from the sibling monica_contacts, leaving the agent to infer that this handles details rather than the contact record itself.

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 bulleted action map (list/add/update/remove) tells the agent which operation to choose for each task, and it routes field-type discovery to monica_reference kind=contact_field_types. It stops short of stating when NOT to use this tool versus a sibling, so it is clear context without exclusions.

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 flag destructiveHint=true broadly, and the description sharpens that by scoping destruction to the delete action and stating it removes 'everything attached to it'. It also discloses non-obvious update semantics ('fields left out are kept, null clears one') and error behavior when a name is ambiguous. No permission or rate-limit context, which keeps it short of a 5.

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 resource, then one bullet per action, each starting with the verb. Dense but zero filler, and the cross-cutting name-or-id rule is placed last as a global note rather than repeated per action.

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 22-parameter, six-action tool with no output schema and sparse schema descriptions, the description covers action selection, the destructive path, and update semantics well. It stops short of mapping parameters to actions or describing the shape of list/search results, but those are secondary given the actions are already disambiguated.

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 only 9% across 22 parameters, so the description must carry the load. It does clarify that only first_name is required for create, that confirm gates delete, that include extends get, and that a name substitutes for an id — but the bulk of profile fields (job, gender, company, birthdate, first_met, deceased, etc.) and the list controls (page, limit, sort) remain undocumented.

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 the resource ('People in Monica, the personal CRM') and then enumerates six distinct verbs — search, list, get, create, update, delete — each with its own scope. An agent can tell contacts apart from monica_notes, monica_activities and the other siblings from 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 explicit routing for the primary entry point ('search — ... Start here when a person is mentioned') and states the precondition for the dangerous action ('delete ... confirm: true'). It does not, however, explain when to prefer this tool over overlapping siblings such as monica_contact_info or monica_relationships, so no exclusion 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 and readOnlyHint=false, so safety is partly covered. The description adds operational context beyond that: delete requires confirm: true, and the action list makes clear which operations mutate versus read. It does not say whether deleting a conversation also destroys its messages, which is the one meaningful remaining gap.

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 resource summary, then a scannable bullet per action with no filler. The opening clause is slightly redundant with the following bullets, but the structure is otherwise tight and well-sized for a five-action tool.

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, five-action tool with no output schema and only 40% schema coverage, the description is only partially complete. The schema explicitly defers per-action field requirements to the tool description ('see tool description'), yet the description never states which fields each action needs — a real gap for create, add_message, and get.

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 only 40% across 10 parameters, so the description needs to compensate. It does explain channel as a contact field type (Email, Phone, Whatsapp, Telegram), the messages array, and the confirm flag, but leaves date, from, limit, and text semantics to the schema, and never maps which fields are required for which action despite the schema's action description pointing to the tool description for 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?

The description names the resource (message threads with contacts, as conversations of messages) and enumerates all five operations with a specific verb each: list, get, create, add_message, delete. An agent can immediately tell this apart from siblings like monica_notes or monica_activities 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?

Each action gets a short gloss ('list — a contact's conversations, or the most recent across everyone'), which implies when to pick it, and delete notes the confirm requirement. However there is no explicit when-not guidance, no prerequisites (e.g. whether a contact must already exist), and no routing to alternatives for overlapping needs.

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 flag destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds meaningful behavioral context beyond that: delete requires 'confirm: true', and a debt 'can be marked settled' via update. It stops short of noting permissions or reversibility, but is solid for an annotated 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?

Purpose is front-loaded, then an efficient bulleted breakdown by action. Dense but every bullet earns its place; no filler sentences.

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 16-param multi-action tool with no output schema and low schema coverage, the description covers the action space and most fields well. Gaps around the list filter (contact), pagination ('limit'), and return shape remain, but given the annotations and lack of output schema these are minor.

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 only 19% schema coverage on 16 params, the description must carry the load, and it largely does — enumerating per-kind fields (name, status, value, url, comment, date for gifts; amount, direction, reason for debts) and mapping id/confirm to update/delete. It leaves 'limit' and 'contact' format unexplained, so it's not exhaustive.

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 resource ('Gifts (ideas, given, received) and money owed between you and contacts') and distinguishes the two sub-kinds (gift vs debt). It clearly conveys CRUD over gifts/debts, though it doesn't explicitly contrast itself against siblings like monica_contacts or monica_notes.

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 tells the agent how to use each action: 'list — a contact's, or everyone's', 'create — gift: ... debt: ...', 'update — by id', 'delete — by id (confirm: true)'. This effectively guides action selection, though it offers no explicit when-not-to-use or alternate-tool 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 destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered structurally. The description adds real value beyond that by stating that delete requires confirm:true, but it never says whether deletes are recoverable, whether update overwrites unspecified fields, or what create/update return.

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?

A single front-loaded definition sentence followed by a tight bullet list per operation — a good structure for a multi-action tool. The bullets are telegraphic ('update — change it'), which trades a little clarity for brevity but wastes no 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?

For a 7-parameter, five-action mutation tool with no output schema and only 43% schema coverage, the description covers the operation surface and two defaults but leaves per-action field requirements, pagination (limit), and return behavior unaddressed.

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 only 43%, and the description compensates only partially: it documents the date default ('today by default') and the confirm flag, and lets the agent infer id for get/update/delete. It says nothing about limit, title, or post, nor which fields each action accepts or requires.

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 the resource precisely ('journal: dated entries about your own days, not tied to a contact') and enumerates the five operations with concrete verbs (list/get/create/update/delete). The phrase 'not tied to a contact' explicitly separates it from sibling tools like monica_notes and monica_activities, so an agent can route 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?

The per-action bullets implicitly tell the agent which operation fits which intent, and delete is flagged as needing confirm: true. There is no explicit when-to-use / when-not-to-use guidance and no alternative tool is named, so routing still relies on 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?

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds the non-obvious safety gate: delete requires confirm: true. It also discloses the environment-dependent upload source (base64 vs. local path over stdio), which is behavior an agent cannot infer from schema or annotations. It does not describe what deletion cascades to, keeping it out of 5 territory.

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 resource, then a compact bulleted mapping of action to requirements — no filler sentences. It is dense enough that the stdio caveat is parenthetical, which is efficient but slightly terse.

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 9-parameter, destructive-capable tool with 22% schema coverage and no output schema, the description covers action semantics and the delete confirmation gate well. It omits pagination behavior (limit) and gives no hint about the return shape for list, which an agent needs when paging through media.

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 only 22%, so the description carries most of the burden and does explain the action-dependent parameter contracts (kind choice, upload's base64/filename/path, delete's id/confirm). However, limit (default 20, max 100) is undocumented in both the description and schema, and the shape of contact/id is left to the schema alone, leaving a real gap.

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 concrete resource (documents and photos attached to contacts) and enumerates the three verbs it supports (list/upload/delete), so an agent immediately knows the domain. It implicitly separates itself from monica_contacts by scoping to attachments, but never explicitly contrasts with a sibling, so it stops short of a 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?

Each action is paired with the condition that selects it and what it operates on: list scopes to a contact's media or everyone's, upload takes base64+filename (or a local path under stdio), delete works by id with confirm. There are no explicit exclusions or named alternatives, but the per-action framing gives clear context for choosing one.

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, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds invocation-critical behavior beyond that: delete requires confirm: true (omitting it would fail the call), and 'favorite pins it' describes a side effect of create/update. It still says nothing about auth or reversibility, keeping it below a 5.

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?

A single front-loaded sentence establishes the resource, then a tight bulleted list handles each action with no filler. Every clause carries information, though the compressed per-action glosses leave some field-mapping detail unstated rather than over-explained.

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 7-parameter, 5-action tool with no output schema and low schema coverage, the description covers the action set well but does not fully specify which fields each action needs or what a call returns. It is adequate for choosing an action but leaves gaps an agent would have to resolve by trial.

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 only 29%, so the description must carry the parameter burden, and it partially does: confirm:true maps to delete, 'favorite pins it' maps to favorite, and 'a contact's notes' implies contact is the filter for list. However it never explicitly maps body/contact/id to the specific actions that require them, so the agent must infer field requirements per action despite the action field's own pointer back to this description.

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 resource ('Notes about contacts: things to remember about someone') and enumerates every operation the tool supports (list/get/create/update/delete) with a short gloss of each. An agent can tell what each action does, though it does not explicitly distinguish notes from the semantically adjacent monica_journal sibling.

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?

Each action is scoped: list returns either a contact's notes or the most recent across everyone, get returns one note in full, create/update write a note, delete removes one. This tells the agent when to pick each branch. It stops short of stating exclusions or alternatives (e.g., when to prefer monica_journal over a note), so it is clear context rather than full routing 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 flag destructiveHint=true and readOnlyHint=false, but the description adds genuinely useful behavioral detail beyond them: it scopes destruction to the delete action and states the safety requirement 'Deleting needs confirm: true.' It also notes the optional protocol format for contact field types. It does not describe what deletion affects or the response, but it meaningfully complements 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?

It front-loads the identity of the resource, then uses bullet separators to break out the actions compactly. Every clause carries information (the enumerations, the protocol example, the confirm requirement). It is appropriately sized with little waste.

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, four-action, destructive tool with no output schema, the description covers the main mechanics but leaves meaningful gaps: 'category' is undocumented, the per-action required/optional field mapping is only gestured at, and with no output schema the shape of list results is unexplained. Adequate but not fully self-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 only 25% (2 of 8 params), so the description must compensate, and it partially does: it explains filter ('optionally filtered by text'), protocol (with the https://instagram.com/ example), confirm: true, and implies name for create/rename plus the kind enumeration. However the 'category' parameter is never mentioned anywhere, and per-action required fields are left as 'see tool description' without being fully spelled out. Net partial compensation.

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 this is Monica's set of reference lists and enumerates the exact kinds (genders, countries, currencies, activity_types, relationship_types, contact_field_types, tags), and it separates what each action does. The framing that these are lists 'which other tools match names against' implicitly but clearly distinguishes it from the sibling entity-CRUD tools. It is clear, though it never states the purpose in a single crisp verb+resource phrase.

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 clear routing context: 'list' returns the values other tools match against, and create/rename/delete apply specifically to 'your own' activity types, contact field types and tags — implying that genders/countries/currencies are read-only. The filter use for list is described. There is no explicit 'do not use this for X' exclusion, so it stops short of a full when/when-not statement.

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, readOnlyHint=false, and non-idempotence, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: that removal requires confirmation, and that Monica auto-creates the inverse relationship, which affects how the agent reasons about state after an add.

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 core concept and direction semantics, then bulleted per action. Dense but every sentence carries information; the type enumeration is long but useful reference 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 6-parameter, no-output-schema tool this covers the conceptual model, all four actions, and the confirm guard. The only shortfall is not spelling out per-action required/optional field combinations despite the action param description deferring to the tool description for exactly that.

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 only 33% (id and action only), so the description must compensate, and it does: it defines contact, type, and other through a concrete worked example and specifies confirm for remove. It stops short of mapping which parameters are required for each action, which is the one remaining gap.

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 resource ('How contacts are related') and enumerates the four operations (list/add/update/remove), so the agent immediately knows the tool's scope. It also routes to the sibling monica_reference for the type vocabulary, distinguishing itself from the other Monica 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?

Each action is annotated with its purpose, and remove explicitly notes the confirm: true prerequisite. The direction convention ('contact is <type> of other', with Monica recording the reverse) tells the agent how to frame add calls. No explicit when-not or alternative-selection guidance beyond the reference lookup.

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 destructiveHint=true already declared, the description still adds real behavioral context: delete requires `confirm: true`, Monica emails reminders when due, and birthday reminders are auto-generated. It does not cover permissions or whether update replaces or merges fields, keeping it out of the top tier.

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 purpose and the email behavior are front-loaded, then actions are laid out as terse bullets with no filler. It is information-dense but readable; a slightly tighter grouping of the create/repeat options would make it cleaner.

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 multi-action mutation tool with no output schema, the description covers action routing, the destructive confirmation, list ordering, and auto-created birthdays. It stops short of describing return shape or update semantics, which an agent might still wonder about.

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 only 30% across 10 parameters, so the description must compensate. It does explain id, date, days (lookahead window), repeat values including 'every N', and confirm, but leaves title, description, contact, and the `every` interval largely unspecified. Partial compensation, hence a middle score.

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 resource (reminders about contacts) and enumerates the four operations the single tool performs, so an agent can see exactly what it does. It is distinct from siblings like monica_contacts or monica_journal, though it never explicitly names those siblings to route between them.

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?

Each action is given a use condition: list for upcoming reminders (soonest first, scoped by contact or the next `days`), create for a dated/repeating reminder, update/delete by id with `confirm: true` for delete. It also tells the agent not to hand-create birthday reminders because Monica does that automatically. No explicit when-not-guidance or named alternatives beyond that.

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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine value by disclosing what the call returns (identity, instance, contact count), which is the key behavioral fact for a diagnostic tool. No pagination or side-effect caveats are needed here.

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 with the purpose and returned fields front-loaded and the usage trigger last. No filler or 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?

With no parameters, no output schema, and annotations covering the safety profile, the description supplies the missing piece an agent needs — what a successful status response contains — and when to invoke it. Nothing material is absent for a tool of this 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?

The tool takes zero parameters, so the baseline is 4. The description correctly does not invent parameter semantics and instead spends its words on return contents, which is the relevant information.

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 (Check) and resource (connection to Monica), then enumerates exactly what it surfaces: the signed-in user, the instance, and the contact count. This clearly separates it from the data-retrieval siblings (monica_contacts, monica_notes, etc.), which fetch records rather than report connection state.

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?

"Useful when other tools fail" gives a concrete trigger condition for reaching for this diagnostic tool instead of the data tools. It stops short of an explicit when-not statement, but for a zero-param health check the intended usage window 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds operationally important detail beyond that: delete requires confirm: true, and list distinguishes open vs done tasks via the done flag. It still omits what update does to unspecified fields or any return-shape information.

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 resource definition, then bullet-lists each action with its key flag. Extremely compact with no redundant sentences.

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 multi-action CRUD tool with no output schema, the description conveys the essential action semantics and the critical confirm guard. It leaves two parameters (limit, description) undocumented and does not describe return values, but for a predictable CRUD surface this is largely adequate.

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 only 25% (just id and action documented), and the action enum explicitly defers per-action field requirements to the tool description. The description partially compensates by mapping actions to done/confirm/contact/id/title, but never mentions limit or description, nor states required fields per action.

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 resource ('To-dos tied to a contact') and enumerates the four actions (list/create/update/delete) with a concrete example, so an agent knows exactly what domain this covers. It does not, however, differentiate itself from the close sibling monica_reminders, which is a plausible source of confusion for a task-like 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?

Gives clear per-action context: list for open tasks (or done ones with done: true), a contact's or everyone's; create for a contact; update to change or toggle done; delete with confirm: true. It stops short of saying when to prefer this over sibling tools such as monica_reminders.

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