This MCP server provides full-coverage integration with Monica CRM through 29 tools, enabling AI assistants to manage personal relationships and contacts across all major Monica API endpoints.
Contact Management
List, get, create, update, delete, and search contacts by name, nickname, email, job, or company
Manage addresses, custom contact fields, contact field types (e.g., Instagram, WhatsApp), companies, occupations, and groups
Assign or remove tags from contacts
Communication & Activities
Log activities (with type, date, emotions) and manage activity types/categories
Log calls and manage conversations across channels, including full message threading (add, update, delete messages)
Productivity & Planning
Full CRUD for notes, tasks (with completion status), reminders (one-time or recurring), tags, and journal entries
Relationships & Finances
Define and track relationships between contacts; browse relationship types and groups (read-only)
Track gifts (ideas, received, offered) with optional photo association
Record debts between you and your contacts
Reference & System Data (Read-Only)
Browse countries, currencies, genders, activity types, and relationship type definitions
View audit logs, authenticated user info, photos, and documents
Safety Features
Read-only mode to block all write operations
Delete protection mode to block only deletions
Tool exclusion to remove specific tools from availability
All delete actions require an explicit action: "delete" parameter and include irreversibility warnings
Provides tools for managing contacts, activities, notes, tasks, reminders, relationships, gifts, debts, and other CRM data in a Monica instance.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@monica-mcp search contacts named Smith"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A full-coverage Model Context Protocol server for Monica CRM. 29 tools covering all 30 API endpoints — search contacts, log activities, manage notes/tasks/reminders, track relationships, and more.
Designed for AI assistants like Claude Desktop, Hermes, Cline, and any MCP-compatible client.
Note: This project is 100% AI-generated. The code, tests, CI/CD, and documentation were all written by an AI agent (Hermes). No human wrote any of the code.
Tested against a live Monica v4.1.2 instance on the author's homelab. All 29 tools validated with create → read → update → delete lifecycle tests. Test data was cleaned up after verification.
Most MCP servers expose 5 separate tools per entity (list, get, create, update, delete). With 30 entities that's 150 tools — flooding the LLM's context window with ~50K+ tokens just for tool definitions. Research shows tool selection accuracy degrades quickly past 15-20 tools.
This server uses one tool per entity with an action parameter:
monica_contact(action: "list" | "get" | "create" | "update" | "delete", ...)Result: 29 tools instead of 150+, ~10-15K tokens for definitions, and better tool selection accuracy.
Delete is an action, not a tool — the AI must explicitly pass action: "delete" rather than calling a tool named "delete"
Read-only mode — set MONICA_READ_ONLY=true to block all write operations
Delete protection — set MONICA_DISABLE_DELETE=true to block only deletes
Tool exclusion — set MONICA_EXCLUDE_TOOLS=monica_contact,monica_tag to remove specific tools
Read-only entities — countries, currencies, genders have no create/update/delete actions
Delete warnings — every tool description includes "⚠️ delete is irreversible"
Related MCP server: mcp-mautic
{
"mcpServers": {
"monica": {
"command": "npx",
"args": ["-y", "monica-mcp"],
"env": {
"MONICA_BASE_URL": "https://your-monica-instance.com",
"MONICA_API_TOKEN": "your-bearer-token"
}
}
}
}{
"mcpServers": {
"monica": {
"command": "npx",
"args": ["-y", "monica-mcp"],
"env": {
"MONICA_BASE_URL": "https://your-monica-instance.com",
"MONICA_API_TOKEN": "your-bearer-token",
"MONICA_READ_ONLY": "true"
}
}
}
}git clone https://github.com/philipp-mlr/monica-mcp.git
cd monica-mcp
npm install
npm run build
MONICA_BASE_URL=https://your-monica-instance.com MONICA_API_TOKEN=your-token node dist/index.jsEnvironment Variable | Required | Default | Description |
| Yes | — | Bearer token for Monica API |
| No |
| Your Monica instance URL |
| No |
| Block all create/update/delete operations |
| No |
| Block only delete operations |
| No | — | Comma-separated tool names to exclude |
In Monica, go to Settings → API → Create New Token. Copy the generated Bearer token.
All 29 tools use an action parameter. Available actions vary per entity — see each tool's description for details.
Tool | Actions | Description |
| list, get, create, update, delete, search, set_tags, update_career, list_activities, list_calls, list_addresses, list_notes, list_tasks, list_reminders, list_gifts, list_debts, list_relationships, list_conversations, list_photos, list_documents, list_fields, list_audit_logs, assign_tag, remove_tag | Full contact management with 15+ contact-scoped sub-queries |
| list, get, create, update, delete | Address CRUD |
| list, get, create, update, delete | Contact field CRUD (email, phone, etc.) |
| list, get, create, update, delete | Contact field type CRUD |
| list, get, create, update, delete | Company CRUD |
| list, get, create, update, delete | Occupation CRUD |
| list, get, create, update, delete | Contact group CRUD |
Tool | Actions | Description |
| list, get, create, update, delete | Activity CRUD |
| list, get, create, update, delete | Activity type CRUD |
| list, get | Activity type categories (read-only) |
| list, get, create, update, delete | Call log CRUD |
| list, get, create, update, delete, list_messages, add_message, update_message, delete_message | Conversation + message threading |
Tool | Actions | Description |
| list, get, create, update, delete | Note CRUD |
| list, get, create, update, delete | Task CRUD |
| list, get, create, update, delete | Reminder CRUD |
| list, get, create, update, delete | Tag CRUD |
| list, get, create, update, delete | Journal entry CRUD |
Tool | Actions | Description |
| list, get, create, update, delete | Relationship CRUD |
| list, get | Relationship types (read-only per API) |
| list, get | Relationship type groups (read-only per API) |
| list, get, create, update, delete, associate_photo | Gift CRUD + photo association |
| list, get, create, update, delete | Debt CRUD |
Tool | Actions | Description |
| list, get | Countries |
| list, get | Currencies |
| list, get | Genders |
| list | Audit logs |
| get | Authenticated user info |
| list, get | Photos (upload not supported by Monica API) |
| list, get | Documents (upload not supported by Monica API) |
Feature | Status | Reason |
Photo upload | Not supported | Monica API returns 405 |
Document upload | Not supported | Monica API returns 405 |
Node.js 18+ — runtime
TypeScript — type safety
@modelcontextprotocol/sdk — MCP protocol implementation
Zod — input validation
Vitest — testing
npm run dev # Start with hot reload (tsx watch)
npm run typecheck # Type-check without emitting
npm test # Run tests (26 tests)
npm test -- --coverage # Run tests with coverageAutomated integration tests — spin up a fresh Monica Docker container in CI, run tools against it, tear it down. This would catch API regressions before they affect users.
Rate limiting — respect Monica's 60 req/min limit with client-side throttling
Photo/document upload — if Monica's API ever supports these, add the tools back
npm release cadence — publish new versions automatically when the version watchdog detects a Monica release that passes integration tests
This package is published to npmjs.com for npx usage.
# 1. Create an npm account at https://www.npmjs.com/signup
# 2. Login on the CLI
npm login
# 3. Verify you're logged in
npm whoami# 1. Bump the version in package.json
npm version patch # 0.1.0 → 0.1.1 (bug fixes)
npm version minor # 0.1.0 → 0.2.0 (new features, backwards compatible)
npm version major # 0.1.0 → 1.0.0 (breaking changes)
# 2. Build and publish
npm run build
npm publish
# Or dry-run first to see what gets published:
npm publish --dry-runThe included GitHub Actions workflow (.github/workflows/release.yml) auto-publishes to npm when a tag v*.*.* is pushed. To use this:
Create an npm Automation access token at https://www.npmjs.com/settings/~/tokens (type must be Automation, not "Publish" — Automation tokens bypass 2FA)
Add it as a GitHub secret: NPM_TOKEN
Tag and push:
npm version patch
git push origin main --tagsMIT
Manage activitys. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| summary | No | Short description | |
| contacts | No | Contact IDs associated with this activity | |
| emotions | No | Emotion IDs | |
| description | No | Detailed description | |
| happened_at | No | Date the activity happened (YYYY-MM-DD) | |
| activity_type_id | No | Activity type ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses delete is irreversible, which is a key behavioral trait. However, it does not mention any other constraints, authorization needs, or side effects.
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?
Extremely concise: two sentences with no wasted words. Front-loads the action list and the critical warning about delete irreversibility.
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?
Despite 10 parameters and no output schema, the description provides minimal context. It does not explain how to use parameters for different actions, what the response looks like, or dependencies. For a CRUD tool with many parameters, more guidance is needed.
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 each parameter has a description. The tool description adds value by explaining the action parameter's semantics (e.g., list = paginated) and warns about delete. This elevates from baseline 3 slightly.
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?
Clearly states the tool manages activities with specific actions (list, get, create, update, delete). This distinguishes it from sibling tools like monica_activity_type and monica_contact.
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?
Lists the actions and warns about delete irreversibility, but does not explicitly guide when to use this tool versus alternatives (e.g., monica_activity_type). Usage is implied by resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage activity_types. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| name | No | ||
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| activity_type_category_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It warns that 'delete is irreversible', which adds important behavioral context. However, it does not disclose other behavioral aspects such as required permissions, side effects of create/update, or response format.
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 extremely concise, consisting of two short sentences and a warning emoji. It front-loads the verb 'Manage activity_types' and efficiently conveys the action list and a critical caveat.
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 six parameters, the description covers the main operations but lacks details about input constraints (e.g., required fields for create), pagination specifics, or error handling. It is adequate but leaves gaps for an AI agent to infer.
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 67%, but the tool description does not add any additional parameter meaning beyond what the schema already provides. For parameters like 'name' and 'activity_type_category_id', which have no schema descriptions, the tool description offers no clarification.
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 manages activity_types and enumerates all supported actions (list, get, create, update, delete). It distinguishes from sibling tools like monica_activity or monica_activity_type_category by focusing on the specific entity 'activity_type'.
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 lists the available actions but does not explicitly state when to use this tool versus alternative tools. Usage is implied by the entity type, but no when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage activity_type_categorys. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the schema: it limits actions to list/get, but the schema supports create, update, delete. No annotations provided to clarify side effects or permissions.
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?
Extremely short (6 words) but under-specified and misleading. Conciseness is not beneficial when it omits critical 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?
Despite full schema coverage, the description lacks context about the entity, typical usage, error handling, or relationship to sibling tools. Incomplete for a CRUD tool.
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 baseline is 3, but the description adds no value and actually misrepresents the action parameter. It does not enhance understanding 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 states 'Manage activity_type_categorys. Actions: list, get.' but the schema action parameter describes additional actions (create, update, delete). The purpose is vague and the listed actions are misleadingly incomplete.
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 tool versus siblings like monica_activity_type. The description provides no context for appropriate usage or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage addresss. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| city | No | City | |
| name | No | Address label (e.g. 'Home', 'Work') | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| street | No | Street address | |
| country | No | Country ID (ISO code) | |
| province | No | Province/state | |
| contact_id | No | Contact ID | |
| postal_code | No | Postal code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency. It only warns that delete is irreversible, which is helpful, but fails to disclose other behaviors such as whether operations are idempotent, require specific permissions, or have side effects beyond the actions listed.
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 very short and front-loaded with the core action list, earning its place without extraneous words. However, the typo 'addresss' slightly marrs an otherwise concise structure.
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?
Despite the schema covering parameters well, the description lacks contextual completeness. It does not explain return values, pagination behavior, error handling, or any integration context. For a tool with 11 parameters and no output schema, more context is needed.
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 input schema has 100% description coverage for all 11 parameters, so the schema already provides solid meaning. The description adds only the note about delete being irreversible, which slightly enriches the action parameter semantics but does not add depth to other 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 indicates that the tool manages addresses and specifies the actions (list, get, create, update, delete), which distinguishes it from sibling tools that manage other entities. However, the verb 'manage' is generic and a typo ('addresss') slightly reduces clarity.
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 guidance on when to use this tool versus alternatives, no context about prerequisites or typical scenarios, and no exclusions. It simply lists actions without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all audit logs in your account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden. It states 'list', implying read-only, but lacks details on pagination, limits, or behavior when no logs exist.
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, clear sentence with no wasted words. It is appropriately 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?
Given the lack of output schema and many sibling tools, the description is somewhat minimal. It does not explain return format or scope, but for a simple list tool it is 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?
The input schema has zero parameters with 100% coverage, baseline is 4. The description adds no parameter semantics, but none are needed.
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 lists audit logs, which is a specific resource. However, it does not explicitly differentiate from siblings like monica_activity or monica_conversation, but 'audit logs' is a distinct concept.
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 is provided on when to use this tool versus alternatives, such as monica_activity or monica_contact. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage calls. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| content | No | Call description/content | |
| called_at | No | Date the call happened (YYYY-MM-DD) | |
| contact_id | No | Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden; it warns about irreversible delete but omits other behaviors like idempotency, return values, or error handling.
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?
Extremely concise with two sentences; no waste, front-loaded with actionable actions and key warning.
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?
Lacks output schema explanation; for a CRUD tool with 7 params, more detail on return values or operation semantics would improve completeness.
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 baseline 3; description adds little beyond schema, only highlighting actions and delete warning.
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 clearly states the tool manages calls with specific actions (list, get, create, update, delete), differentiating it from sibling tools that manage other resources.
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 implicitly indicates when to use (for call management) but lacks explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage companys. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| name | No | Company name | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| website | No | Company website URL | |
| number_of_employees | No | Number of employees |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a warning that delete is irreversible, which is a key behavioral trait. However, with no annotations provided, the description fails to disclose other behaviors such as authorization needs, idempotency, or side effects beyond the delete warning.
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 very short (two sentences) and to the point, with no unnecessary words. The warning is effectively placed. However, it could be slightly more structured, e.g., listing actions in a bulleted format.
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 tool has 7 parameters and no output schema or annotations, the description is inadequate. It does not explain pagination for list, required fields for create/update, or the return structure, leaving significant gaps for an agent to use it correctly.
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 input schema already describes all parameters. The description adds no extra meaning beyond what is in the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages 'companys' (company records) and lists the available CRUD actions, making the purpose clear. However, it does not differentiate from sibling tools that also manage other entities, and the typo 'companys' slightly reduces clarity.
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 guidance on when to use this tool versus alternatives. It does not explain when to choose 'list' over 'get', or under what circumstances to use this tool over similar monica_* tools for other entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage contacts. Actions: list, get, create, update, delete. ⚠️ delete is irreversible. Additional actions: search, set_tags, update_career, list_activities, list_calls, list_addresses, list_notes, list_tasks, list_reminders, list_gifts, list_debts, list_relationships, list_conversations, list_photos, list_documents, list_fields, list_audit_logs, assign_tag, remove_tag.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| job | Yes | Job title | |
| page | No | Page number | |
| sort | No | Sort: created_at, -created_at, updated_at, -updated_at | |
| tags | Yes | Array of tag names to set | |
| limit | No | Page size (max 100) | |
| query | No | Search query (searches name, nickname, email, job, company) | |
| action | Yes | Operation to perform: list | get | create | update | delete | search | set_tags | update_career | list_activities | list_calls | list_addresses | list_notes | list_tasks | list_reminders | list_gifts | list_debts | list_relationships | list_conversations | list_photos | list_documents | list_fields | list_audit_logs | assign_tag | remove_tag. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| tag_id | Yes | Tag ID to remove | |
| company | Yes | Company name | |
| nickname | No | Nickname | |
| birthdate | No | Birthdate (YYYY-MM-DD) | |
| gender_id | No | Gender ID | |
| last_name | No | Last name | |
| first_name | No | First name | |
| is_partial | No | Whether this is a partial contact | |
| is_deceased | No | Whether contact is deceased | |
| birthdate_age | No | ||
| deceased_date | No | ||
| food_preferencies | No | ||
| is_birthdate_known | No | Whether birthdate is known | |
| birthdate_is_age_based | No | ||
| is_deceased_date_known | No | Whether deceased date is known | |
| stay_in_touch_frequency | No | ||
| birthdate_is_year_unknown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It warns that 'delete is irreversible' using a warning symbol, which is good. However, it does not disclose other behaviors like read/write safety, rate limits, or side effects of other actions.
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 front-loaded with 'Manage contacts,' but then becomes a long enumeration of actions. It is somewhat verbose but structured with a warning and two lists. Could be more concise by grouping similar actions.
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?
The tool has 25 parameters and no output schema. The description lacks information about data model, parameter dependencies, and action-specific requirements. For example, 'update_career' is listed but not explained. Pagination and sorting are partially covered in schema but not in description.
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 76%, which is high. The description lists actions but adds little meaning beyond the schema's parameter descriptions. It does not elaborate on parameter usage or constraints beyond what schema already provides. Baseline 3 is 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 starts with 'Manage contacts,' which clearly identifies the resource. The list of actions (list, get, create, update, delete) provides specific verbs. However, the description is more of a menu than a concise verb-resource statement, lacking a focused purpose. It distinguishes from siblings by targeting contacts.
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 on when to use this tool versus alternatives. It lists actions but does not explain context or trade-offs. No sibling comparison or situational advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage contact_fields. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| data | No | Field content (e.g. email address, phone number) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| contact_id | No | Contact ID | |
| contact_field_type_id | No | Contact field type ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that delete is irreversible, which is a critical behavioral trait. However, no annotations are provided, and the description does not cover other side effects, authentication needs, or rate limits. With no annotations, the description carries the full burden but only partially addresses it.
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?
Extremely concise: two sentences with no redundant information. Every word serves a purpose, listing the resource and actions with a critical warning.
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 7 parameters, no output schema, and no annotations, the description is minimal. It lacks details on return values, error handling, default behavior for list (e.g., default page/limit), and relationships with other entities. However, for a straightforward CRUD tool, it provides a functional baseline.
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 tool description adds minimal value beyond the schema; it lists actions but does not elaborate on parameter usage or examples. The schema already describes each parameter adequately.
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?
Clearly states it manages contact_fields with specific CRUD actions: list, get, create, update, delete. Distinguishes from sibling tools by specifying the resource (contact_fields) and the operations.
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 tool versus alternatives like monica_contact_field_type or monica_contact. The description only lists actions without explaining scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage contact_field_types. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| name | No | Field type name (e.g. 'Instagram') | |
| page | No | Page number | |
| type | No | Type: email, phone, whatsapp, etc. | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| delible | No | Whether this type can be deleted | |
| protocol | No | Protocol (e.g. 'mailto:') | |
| fontawesome_icon | No | FontAwesome icon class |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It warns that delete is irreversible and describes each action's behavior in the action parameter (e.g., 'list = paginated list'). However, it does not disclose auth requirements, rate limits, or other behavioral traits.
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 extremely concise: two sentences highlighting actions and irreversibility of delete, with no wasted words. It is front-loaded with the core purpose.
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 CRUD tool with no output schema, the description covers actions and required parameters via the action parameter. It lacks explanation of return values or error handling, but overall it is sufficient for an agent to understand how to invoke the tool.
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 baseline is 3. The action parameter description adds meaning beyond the schema by explaining each action's semantics. Other parameter descriptions (e.g., 'Entity ID (required for get/update/delete)') add context, making the description more useful.
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 it manages contact_field_types and lists actions (list, get, create, update, delete). It clearly indicates the resource and verb, distinguishing it from sibling tools like monica_contact_field which deals with contact fields themselves.
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 explicit guidance on when to use this tool versus alternatives. The description only lists actions and a warning, but does not provide context for choosing this over other Monica tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage conversations. Actions: list, get, create, update, delete. ⚠️ delete is irreversible. Additional actions: list_messages, add_message, update_message, delete_message.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete | list_messages | add_message | update_message | delete_message. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| contact_id | No | Contact ID | |
| message_id | Yes | Message ID to delete | |
| written_at | No | When written (YYYY-MM-DD) | |
| written_by_me | No | Whether written by me | |
| message_content | Yes | Updated message content | |
| conversation_content | No | Initial message content | |
| contact_field_type_id | No | Contact field type ID (channel) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions that delete is irreversible. Given no annotations, it should disclose more behavioral traits such as side effects of other actions, required permissions, rate limits, or idempotency. The current disclosure is minimal.
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 concise, consisting of two sentences. However, given the complexity of 11 parameters and 9 actions, it could be better structured to quickly convey required parameter combinations 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?
The description lacks explanation of usage patterns, required parameter combinations for each action, and common workflows. Without output schema or annotations, the agent is left to infer how to invoke actions correctly, leading to potential errors.
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?
All parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The tool description does not add any further semantic value 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?
The description states the resource ('conversations') and lists multiple actions, making the tool's purpose clear. However, it does not differentiate from sibling CRUD tools like monica_contact or monica_note, which likely have similar action patterns.
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 is provided on when to use this tool versus alternatives. The only conditional advice is a warning about irreversible delete, but there is no information about prerequisites, context, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage countrys. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only mentions list and get, omitting create, update, delete operations, and fails to explain any side effects, authentication needs, or constraints. This is a significant 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?
The description is extremely brief but this is not concise—it is under-specified and inaccurate. Every sentence should add clarity; this one does not.
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 tool has 4 parameters, no output schema, and no annotations, the description is critically incomplete. It provides no context on return values, pagination, or error states, leaving the agent without essential information.
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?
Although schema coverage is 100%, the description adds no value beyond the schema. It actually misrepresents the action parameter by only listing two operations, contradicting the schema's enum. Parameter semantics are degraded.
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 'Manage countrys. Actions: list, get.' but the schema reveals additional actions (create, update, delete) not mentioned. This is misleading and incomplete, failing to convey the full scope of the tool's capabilities.
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 is provided on when to use this tool versus its siblings, which include many similar entity management tools. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage currencys. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'list' and 'get' but omits the create, update, and delete actions that appear in the schema, and provides no warnings about destructive operations like delete being irreversible.
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 very concise (one sentence) but lacks structure and completeness. While short, it omits important details, making it merely average.
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 4 parameters, no output schema, and many sibling tools, the description is insufficient. It does not explain return values, pagination behavior, or how to use the id parameter, leaving significant 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?
The input schema has 100% coverage of parameter descriptions, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides; it merely echoes the action values.
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 says 'Manage currencys. Actions: list, get.' The verb 'Manage' is vague, and the listed actions are incomplete compared to the schema which includes create, update, and delete. This misalignment reduces clarity.
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 is provided on when to use this tool versus the many sibling tools (e.g., monica_activity, monica_contact). The description lacks any context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage debts. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| amount | No | Debt amount | |
| reason | No | Debt reason | |
| status | No | Debt status: 'inprogress' or 'complete' | |
| in_debt | No | Who is in debt: 'yes' (user owes contact) or 'no' (contact owes user) | |
| contact_id | No | Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that delete is irreversible, which is useful. However, it lacks details on other behavioral aspects like authorization needs, side effects of updates, or rate limits. Since no annotations exist, the description carries the full 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 very short and to the point, with no wasted words. It could be more structured, but it is efficient.
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 tool's moderate complexity (9 params, no output schema), the description is minimal. It fails to explain how the action parameter drives behavior or the overall workflow, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description adds no extra meaning beyond listing actions, so it meets 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 it manages debts with explicit CRUD actions (list, get, create, update, delete). The sibling tools are for different entities, so it is distinct and 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage documents. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states actions. It fails to disclose behavioral traits such as destructive operations (delete), authentication needs, or rate limits. The schema mentions irreversibility for delete, but the description omits this.
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 concise but under-specified. It lacks necessary details to effectively guide an AI agent, missing essential context for each 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?
Given no output schema and four parameters, the description should provide more context (e.g., return format, pagination). It does not, leaving the tool incomplete for effective use.
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 baseline is 3. The description adds no parameter information 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?
The description 'Manage documents. Actions: list, get.' presents a general verb 'Manage' and lists two actions, offering moderate clarity. However, the schema's action description includes create, update, delete, causing inconsistency and reducing clarity.
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 is provided on when to use this tool or when to choose between list and get. Sibling tools like monica_note exist, but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage genders. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description fails to disclose that delete is irreversible (schema mentions it but description omits), and does not explain create/update behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Too brief; only two phrases. Omits critical actions (create, update, delete) from the description, sacrificing completeness for conciseness.
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?
Missing output schema and behavioral context. For a 4-parameter tool, description is insufficient. No hints on return values or side effects.
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 covers 100% of parameters with good descriptions. Tool description adds no extra meaning, so baseline 3.
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 says 'Manage genders' which is vague, and only mentions 'list, get' while the schema supports create, update, and delete, making the description misleading.
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 tool versus siblings like monica_contact or monica_activity. Context lacks decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage gifts. Actions: list, get, create, update, delete. ⚠️ delete is irreversible. Additional actions: associate_photo.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| url | No | Gift URL | |
| date | No | Gift date (YYYY-MM-DD) | |
| name | No | Gift name | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete | associate_photo. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| amount | No | Gift amount | |
| status | No | Gift status: idea, received, offered | |
| comment | No | Gift comment | |
| photo_id | Yes | Photo ID to associate | |
| contact_id | No | Contact ID | |
| recipient_id | No | ID of the contact the gift is for (partner/child) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral disclosure is that delete is irreversible. No annotations exist, so the description should detail side effects, authentication needs, or rate limits. The tool has multiple mutation actions, but transparency is minimal, leaving the agent without critical behavioral context.
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 very short, consisting of two sentences that efficiently convey the tool's scope and a key warning. It is well front-loaded with 'Manage gifts' and action list, with no wasted 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?
Given the complexity of 13 parameters, multiple actions, no output schema, and no annotations, the description is too minimal. It lacks information on return format, error handling, parameter constraints per action, and relationships, leaving the agent without sufficient context to use the tool effectively.
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 input schema has 100% coverage with descriptions for each parameter, so the description adds no semantic value beyond the schema. It lists actions but does not elaborate on parameter usage, so baseline 3 is 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 states it manages gifts and lists actions (list, get, create, update, delete, associate_photo), clearly indicating the resource and operations. However, it does not differentiate from sibling tools beyond the subject matter, but siblings are distinct entities, so it is adequate.
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 use for gift operations by naming the resource, but provides no explicit guidance on when to use or not use this tool compared to alternatives. Since siblings cover different entities, the usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage groups. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| name | No | Group name | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Warns that delete is irreversible, which is critical behavioral info. No other behavioral traits disclosed (e.g., authentication, rate limits, side effects). With no annotations, more burden falls on the description, so a 3 is appropriate.
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 total: first states purpose, second lists actions with a warning. 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?
Minimal information: actions and irreversibility of delete. No mention of return values, error handling, pagination details (though schema covers page/limit). Adequate for a simple CRUD tool but not rich.
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% with descriptions for each parameter. The description lists actions but adds no further semantic value beyond what the schema already provides. Baseline score of 3.
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?
Clearly states the tool manages groups and lists all supported actions (list, get, create, update, delete). The entity 'groups' distinguishes it from sibling tools targeting other entities.
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?
Implied usage: use for group management. No explicit when-to-use or when-not-to-use alternatives, but the entity-based context makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage journal_entrys. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| post | No | Journal entry content | |
| limit | No | Page size (max 100) | |
| title | No | Journal entry title | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that delete is irreversible, which is important behavioral information. However, with no annotations, the description should also disclose other behaviors such as required fields for create, update semantics, or pagination details, which are absent.
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 very concise with two sentences, no wasted words, and front-loaded with purpose. However, it could be slightly more informative without losing conciseness.
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 6 parameters, full schema coverage, and no output schema or annotations, the description provides a high-level overview but lacks details on pagination, field requirements, and error cases. It is adequate but not fully comprehensive.
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 adds little beyond listing actions and warning about delete; the schema already documents each parameter adequately.
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 manages journal entries and lists the five actions (list, get, create, update, delete). It effectively distinguishes from sibling tools which are for other entities.
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 lists the available actions, providing clear context for when to use each. However, it does not explicitly state when not to use this tool or mention alternatives, though sibling names imply entity-specific usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage notes. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| body | No | Note content | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| contact_id | No | Contact ID | |
| is_favorited | No | Favorited: 0 (false) or 1 (true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially compensates by warning that delete is irreversible. However, it fails to disclose other behavioral traits like authentication requirements, side effects of other actions, or rate limits.
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 concise with two sentences, front-loading the core purpose. Every word earns its place, though it could be more structured (e.g., grouping actions by type).
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 tool has 7 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the output format of list/get, the meaning of 'body' or 'contact_id', or the context for using each action. The agent lacks enough information to use the tool correctly.
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 parameters are well-documented in the schema. The description adds minimal value beyond listing actions; it does not explain how parameters like 'id' relate to specific actions or provide usage patterns.
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 handles notes and lists specific actions (list, get, create, update, delete). This verb+resource clarity distinguishes it from other monica_* sibling tools, though it could be more specific about what constitutes a note.
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 the tool is for note management but provides no explicit guidance on when to use this tool versus alternatives or which action to choose. The action parameter descriptions in the schema help, but the description itself lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage occupations. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| title | No | Job title | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| salary | No | Estimated salary | |
| end_date | No | End date (YYYY-MM-DD) | |
| company_id | No | Company ID | |
| contact_id | No | Contact ID | |
| start_date | No | Start date (YYYY-MM-DD) | |
| description | No | Job description | |
| salary_unit | No | Salary unit: year, month, week, day, hour | |
| currently_works_here | No | Whether the contact currently works here |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It notes that 'delete is irreversible,' which is critical. However, it omits other behaviors such as authorization requirements, rate limits, side effects of updates, or whether list returns all records or requires pagination context beyond the schema.
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 efficiently convey the core purpose and a critical warning. No redundant words; the information is front-loaded and well-structured.
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 complexity (13 parameters, no output schema, no annotations), the description is adequate for simple CRUD but lacks explanation of return format, pagination behavior, error handling, and relationships with other entities. It meets minimum viability but has 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?
The input schema covers all 13 parameters with full descriptions, so the description adds no additional meaning beyond what the schema already provides. The baseline of 3 is 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 clearly states the resource (occupations) and verb (Manage), and lists five specific actions, making its purpose immediately clear. While it distinguishes from siblings by naming the resource, it does not differentiate the scope or behavior from other Monica CRUD tools with similar patterns.
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 enumerates the allowed actions and warns about delete irreversibility, which provides basic usage constraints. However, it offers no guidance on when to choose this tool over siblings (e.g., monica_contact, monica_company), nor does it explain prerequisites or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage photos. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description omits the destructive actions (create, update, delete) that are listed in the input schema and fails to mention that delete is irreversible. This misleads the agent about the tool's capabilities and behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not effectively concise; it omits essential information and is inaccurate. It does not earn its place as it fails to clarify the tool's purpose.
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 lack of output schema and the presence of multiple actions (including destructive ones), the description is completely inadequate. It does not explain return values, error handling, or use cases.
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?
Although the input schema has 100% coverage and detailed parameter descriptions, the tool description adds no additional meaning. It only mentions 'list, get' despite the schema supporting more actions, causing confusion.
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 'Manage photos. Actions: list, get.' is tautological and vague. It fails to specify what kind of photos or the broader context, and it understates the actual available actions compared to the input 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?
No guidance on when to use this tool versus alternatives, nor explanation of the appropriate context for each action. The description does not help the agent choose between monica_photo and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage relationships. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| contact_is | No | ID of the primary contact | |
| of_contact | No | ID of the secondary contact | |
| relationship_type_id | No | Relationship type ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that 'delete is irreversible,' which adds behavioral context. However, it does not disclose other important traits such as whether updates are partial or full, authorization requirements, or side effects. Since annotations are absent, the description carries the full burden but only partially fulfills it.
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 concise, consisting of two short sentences. It efficiently conveys the tool's scope and a critical warning. No unnecessary 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?
Given the tool's complexity (CRUD with 7 parameters) and no output schema, the description is incomplete. It does not explain return values, pagination behavior for list, or nuances of create/update operations. The schema provides structure but the description misses key contextual details.
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 does not add significant meaning beyond the schema; it merely summarizes the actions. The schema already explains each parameter adequately.
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 'Manage relationships' and lists the CRUD actions (list, get, create, update, delete), making the tool's purpose evident. However, it does not explicitly differentiate this tool from sibling tools like monica_contact or monica_relationship_type, which could cause ambiguity.
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 is provided on when to use this tool versus alternatives (e.g., when to use list vs get, or which sibling tool to choose for a given task). The description lacks explicit context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage relationship_types. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'Manage relationship_types. Actions: list, get.' and does not mention side effects, permissions, or idempotency. The schema's action parameter descriptions provide some detail, but the description adds no behavioral context.
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 very short (one sentence) but at the cost of completeness and accuracy. Conciseness is acceptable, but misleading content reduces its effectiveness.
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 tool has 4 parameters, 1 required, no output schema, and no annotations, the description is insufficient. It does not explain what a relationship type is, how to use the actions effectively, or how it relates to other tools. Significant gaps remain for the agent to understand its role.
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?
Although schema description coverage is 100%, the description adds no meaning beyond the schema and actually contradicts it by stating only 'list' and 'get' actions while the schema supports all five. This mismatch reduces clarity and fails to add value.
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 'Manage relationship_types. Actions: list, get.' which identifies the resource and listed actions but is vague about the full scope. The schema includes additional actions (create, update, delete) that are omitted, making it misleading. It does not differentiate from sibling tools like monica_relationship or monica_relationship_type_group.
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 is provided on when to use this tool versus siblings. There is no mention of prerequisites, context, or situations where alternatives are better. The description lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage relationship_type_groups. Actions: list, get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description omits destructive actions (create, update, delete) that are present in the schema, potentially leading an agent to think the tool is read-only. No annotations are provided, so the description carries full burden for behavioral disclosure but fails to mention side effects or irreversible operations.
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?
Very short (two sentences) but sacrifices accuracy and completeness. Frontal loading is minimal. While concise, the brevity leads to missing critical information about the tool's full capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should compensate by explaining return values or behavioral details. It fails to do so. Only 2 of 5 possible actions are mentioned, and there is no context about pagination, filtering, or other behaviors relevant to a 4-parameter tool.
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 has 100% coverage, so baseline is 3, but the description adds no value and actually undermines the schema by listing only two actions. It does not explain parameters beyond what the schema already provides, and it misrepresents the allowed actions.
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 'Manage relationship_type_groups' which is vague and doesn't distinguish from sibling tools like monica_relationship_type. The description claims only list and get actions, but the schema includes create, update, delete, making the purpose statement inaccurate.
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 tool versus alternatives (e.g., monica_relationship_type). Does not specify any use cases or conditions for using create/update/delete actions, which are mentioned in the schema but omitted from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage reminders. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| title | No | Reminder title | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| contact_id | No | Contact ID | |
| description | No | Reminder description | |
| frequency_type | No | Frequency type: one_time, week, month, or year | |
| frequency_number | No | Frequency interval (for recurring reminders) | |
| next_expected_date | No | Trigger date (YYYY-MM-DD, must be in the future) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It warns that delete is irreversible, which is helpful, but omits other behaviors like auth needs, rate limits, or side effects of create/update.
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 very concise with one sentence and a warning, front-loading the core purpose. Could be slightly more structured but effectively communicates essentials.
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 tool has 10 parameters and no output schema, the description is adequate but lacks details on return values, pagination behavior, or required relationships, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides for each parameter.
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 manages reminders and lists specific actions (list, get, create, update, delete), making it distinct from sibling tools which handle different entities.
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 through 'Manage reminders' and action list, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage tags. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| name | No | Tag name | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| description | No | Tag description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It warns that delete is irreversible, but does not disclose other behavioral traits like required permissions, rate limits, or side effects of create/update.
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 redundancy. First sentence states purpose and actions, second adds a crucial warning. Efficient and well-structured.
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?
The description is minimal but adequate for a simple CRUD tool given that the schema covers parameter details. However, lacking output schema and annotations, it could add more context about return values or pagination behavior.
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 explains each parameter. The description adds no extra meaning beyond listing the actions, which is already 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 clearly states it manages tags and lists all CRUD actions (list, get, create, update, delete). This provides a specific verb+resource and distinguishes from sibling tools which manage other entities.
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 explicit guidance on when to use this tool vs alternatives. While siblings are different entities, the description does not offer selection criteria or context-specific advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage tasks. Actions: list, get, create, update, delete. ⚠️ delete is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Entity ID (required for get/update/delete) | |
| page | No | Page number | |
| limit | No | Page size (max 100) | |
| title | No | Task title | |
| action | Yes | Operation to perform: list | get | create | update | delete. "list" = paginated list, "get" = by ID, "create" = new record, "update" = modify by ID, "delete" = remove by ID (irreversible). | |
| completed | No | Status: 0 (incomplete) or 1 (complete) | |
| contact_id | No | Contact ID | |
| description | No | Task description | |
| completed_at | No | Completion date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only notes that delete is irreversible. Lacks disclosure of authentication needs, idempotency, rate limits, or other behavioral aspects beyond the single warning.
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?
Extremely concise: one line plus a warning. Information is front-loaded but could benefit from separating action descriptions per parameter.
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 9 parameters and no output schema, the description is insufficient. Does not explain return values, pagination behavior, or how actions interact with required vs optional parameters.
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 parameters. The description does not add significant meaning beyond listing actions; baseline 3 is 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?
Clearly states the tool manages tasks and enumerates all actions (list, get, create, update, delete). Distinguishes from sibling tools which manage other resources like contacts or activities.
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 explicit guidance on when to use this tool versus alternatives. However, the sibling list implies it is for tasks specifically, so context is clear but no exclusions or when-not advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently authenticated user's information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation but does not disclose any behavioral traits like authentication requirements, rate limits, or data freshness. Adequate but not detailed.
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?
Single sentence, front-loaded with verb and resource, no wasted 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?
Given no output schema and low complexity, the description covers the basic purpose. Lacks detail on return fields, but is sufficient for a simple retrieval tool.
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?
Zero parameters and 100% schema coverage; description adds meaning beyond the empty schema by specifying what is retrieved (authenticated user's 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?
The description clearly states the verb 'Get' and the resource 'currently authenticated user's information', distinguishing it from sibling tools which target specific entities like activities, contacts, etc.
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 context is clear: use to retrieve the authenticated user's info. No explicit exclusions or alternatives, but the purpose is unambiguous and distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0monica_activitymonica_activity_typemonica_activity_type_categorymonica_addressmonica_audit_logmonica_callmonica_companymonica_contactmonica_contact_fieldmonica_contact_field_typemonica_conversationmonica_countrymonica_currencymonica_debtmonica_documentmonica_gendermonica_giftmonica_groupmonica_journal_entrymonica_notemonica_occupationmonica_photomonica_relationshipmonica_relationship_typemonica_relationship_type_groupmonica_remindermonica_tagmonica_taskmonica_userEach tool is named after a distinct entity (e.g., monica_contact, monica_call) and clearly specifies the actions supported. Over 29 tools, no two appear to cover the same domain, making selection unambiguous.
All tools follow a consistent pattern: 'monica_' followed by a singular noun in snake_case (e.g., monica_activity_type). No mixing of conventions or verb-noun styles; uniformity is high.
29 tools are appropriate for a comprehensive personal CRM server covering contacts, activities, calls, notes, tasks, etc. While slightly on the higher side, each tool corresponds to a well-defined entity and earns its place.
The tool set offers full CRUD for most major entities (contacts, activities, calls, tasks, etc.) and includes additional actions like search and tagging. Minor gaps exist (e.g., documents only have list/get, no create/update/delete), but overall coverage is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
Secure MCP server for exploring incwo CRM data, documents, and email workflows.
A CRM powered by your agent: contacts, deals, email, ads, and reports over MCP.
Cross-product MCP server for CRM, LeadKit, ProjectKit, Bookio. 10 action types, MIT open spec.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/philipp-mlr/monica-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
