FluentCRM MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, with clear boundaries between operations like create/delete/list/update. However, some potential ambiguity exists between 'fluentcrm_find_contact_by_email' and 'fluentcrm_get_contact' as both retrieve contact details, though the former specifies email search while the latter likely uses ID. The 'fluentcrm_custom_fields' tool also stands out as a read-only operation amidst mostly CRUD tools, but descriptions clarify its purpose.
Naming Consistency5/5
All tools follow a highly consistent 'fluentcrm_verb_noun' pattern with snake_case throughout. The verb choices are logical and predictable (create, delete, list, get, update, attach, detach, etc.), making the tool set easy to navigate and understand at a glance. No deviations in naming conventions are present.
Tool Count2/5
With 36 tools, the count is excessive for a CRM server, creating cognitive overhead and potential redundancy. While the domain is broad, many tools could be consolidated (e.g., separate attach/detach for lists and tags might be combined, or campaign pause/resume could be a single toggle). This volume suggests over-engineering rather than a well-scoped surface.
Completeness5/5
The tool set provides comprehensive coverage for FluentCRM's domain, including full CRUD operations for core resources (contacts, lists, tags, campaigns, templates, webhooks, automations), plus additional utilities like dashboard stats, custom fields, and smart link management. There are no obvious gaps; agents can perform end-to-end workflows from contact creation to campaign management.
Average 2.6/5 across 36 of 36 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('creates') without disclosing behavioral traits like permissions required, whether it's idempotent, what happens on failure, or what the output looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Polish, which is efficient but under-specified. While it's front-loaded with the core action, it lacks necessary detail, making brevity come at the cost of clarity rather than being a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating an automation with 3 parameters), lack of annotations, no output schema, and incomplete schema coverage, the description is severely inadequate. It doesn't address what an automation is, how it behaves, or what to expect after creation, leaving critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds no parameter information beyond what's in the schema—it doesn't explain what 'automation' entails, provide examples for 'trigger' types, or clarify the purpose of the 'description' field. With low coverage, it fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tworzy nową automatyzację' (Creates a new automation) restates the tool name 'fluentcrm_create_automation' in Polish, making it tautological. It doesn't specify what 'automation' means in this context or differentiate it from sibling tools like 'fluentcrm_create_campaign' or 'fluentcrm_create_webhook', which also create resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It doesn't mention prerequisites, dependencies, or when other tools like 'fluentcrm_list_automations' might be more appropriate. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions potential unavailability but doesn't explain what 'Smart Link' is, what permissions are required, whether this is a destructive operation, what happens on success/failure, or any rate limits. The description fails to disclose essential behavioral traits for an update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence with a parenthetical), which could be efficient if it contained useful information. However, the content is mostly wasted on a tautology and vague warning. While structurally simple, it fails to deliver meaningful content in its concise form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter update tool with no annotations, no output schema, and minimal schema documentation, the description is completely inadequate. It doesn't explain what a Smart Link is, what fields can be updated, what the operation does, what permissions are needed, or what to expect as a result. The vague availability warning adds confusion rather than completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 13% schema description coverage (only 'smartLinkId' has a description), the description provides no parameter information to compensate. It doesn't explain what 'apply_tags', 'remove_lists', 'auto_login', or other parameters mean, their expected formats, or how they interact. The description adds zero semantic value beyond the minimal schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualizuje Smart Link' (Updates Smart Link) is a tautology that restates the tool name 'fluentcrm_update_smart_link' in Polish. It adds no meaningful clarification about what 'Smart Link' refers to or what specific aspects are updated. The parenthetical note about potential unavailability adds confusion rather than clarifying purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'fluentcrm_create_smart_link', 'fluentcrm_get_smart_link', 'fluentcrm_delete_smart_link', or 'fluentcrm_list_smart_links' that handle related operations. The warning about potential unavailability is vague and doesn't specify conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'creates' which implies a write/mutation operation, but doesn't disclose any behavioral traits such as permissions required, whether the creation is idempotent, what happens on duplicate URLs, or what the response looks like (since no output schema exists). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words in Polish ('Tworzy nowy webhook'), which is appropriately sized for its limited content. It's front-loaded with the core action, though this brevity comes at the cost of completeness. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation), lack of annotations, and no output schema, the description is completely inadequate. It doesn't explain what a webhook does in this context, how it integrates with FluentCRM, what events it triggers, or provide any operational details. For a creation tool with multiple parameters, this leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (2 out of 5 parameters have descriptions: 'name' and 'url'), and the description adds no information about parameters beyond what's in the schema. It doesn't explain what 'tags' and 'lists' arrays refer to, the meaning of 'status' enum values, or provide any context for required fields. With low coverage and no compensation in the description, this fails to add meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tworzy nowy webhook' (Creates a new webhook) is a tautology that essentially restates the tool name 'fluentcrm_create_webhook' in Polish. It doesn't specify what kind of webhook (e.g., for what events or system) or provide any distinguishing details from sibling tools like 'fluentcrm_list_webhooks'. The purpose is clear at a basic level but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 doesn't mention prerequisites, when webhooks are appropriate compared to other methods, or how it relates to sibling tools like 'fluentcrm_list_webhooks' for viewing existing webhooks. There's complete absence of usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether pausing is reversible, requires specific permissions, affects ongoing emails, or has side effects. The single word 'Wstrzymuje' (Pauses) lacks context on outcomes or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with one word, the description is under-specified rather than efficiently structured. It lacks front-loaded critical information and fails to earn its place by providing insufficient value, making it ineffective despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what pausing entails, potential impacts, success criteria, or return values, leaving significant gaps in understanding for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'campaignId' clearly documented in the schema as 'ID kampanii' (campaign ID). The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wstrzymuje kampanię' (Pauses a campaign) is a tautology that restates the tool name 'fluentcrm_pause_campaign' without adding specificity. It doesn't clarify what 'pause' means operationally or distinguish it from sibling tools like 'fluentcrm_resume_campaign' or 'fluentcrm_delete_campaign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 description doesn't mention prerequisites (e.g., campaign must be active), exclusions, or relationships to sibling tools like 'fluentcrm_resume_campaign' for resuming or 'fluentcrm_delete_campaign' for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but offers no behavioral details. It doesn't disclose whether this is a read/write operation, what permissions are needed, if it's idempotent, what happens on success/failure, or any side effects (e.g., resuming email sends). This leaves the agent guessing about critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, front-loading the core action. There is no wasted language, though this brevity contributes to underspecification in other dimensions. For conciseness alone, it earns full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a campaign management tool with no annotations and no output schema, the description is severely incomplete. It lacks essential context like what 'resuming' means operationally, expected outcomes, error conditions, or dependencies. This leaves the agent ill-equipped to use the tool effectively in a real-world scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'campaignId' documented as 'ID kampanii' (campaign ID). The description adds no additional meaning beyond the schema, such as format examples or constraints. However, with high schema coverage and only one parameter, the baseline of 3 is appropriate as the schema adequately defines the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wznawia kampanię' (Resumes a campaign) restates the tool name in Polish without adding specificity. It doesn't clarify what 'resuming' entails operationally or distinguish this tool from sibling tools like 'fluentcrm_pause_campaign' or 'fluentcrm_create_campaign'. The purpose is vague beyond the basic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It doesn't mention prerequisites (e.g., the campaign must be paused), exclusions, or relationships with sibling tools like 'fluentcrm_pause_campaign' or 'fluentcrm_delete_campaign'. The agent receives no contextual cues for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Pobiera' implies a read operation, but it doesn't disclose behavioral traits such as whether it returns all webhooks, supports pagination, requires authentication, or has rate limits. For a tool with zero annotation coverage, this leaves critical operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Pobiera webhooks'), which could be efficient but risks under-specification. It's front-loaded with the core action, but lacks any supporting context. While not verbose, it may be too brief to be fully helpful, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It doesn't explain what the tool returns (e.g., list structure, error handling) or any behavioral nuances. For a retrieval tool, more context on output and usage is needed to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pobiera webhooks' (Polish for 'Retrieves webhooks') states the basic action but is minimal and lacks specificity. It doesn't clarify what 'webhooks' refers to (e.g., in FluentCRM context) or how they are retrieved (e.g., as a list, with filtering). Compared to siblings like 'fluentcrm_list_contacts' or 'fluentcrm_list_tags', it doesn't distinguish itself beyond the resource name, making it vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It doesn't mention prerequisites, context (e.g., after creating webhooks), or comparisons to other list tools (e.g., 'fluentcrm_list_automations'). The agent must infer usage from the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action 'deletes' but does not elaborate on critical aspects: whether this is irreversible, requires specific permissions, has side effects (e.g., on associated contacts or automations), or what happens on success/failure. For a destructive operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single word ('Usuwa kampanię'), which is front-loaded and wastes no space. It directly states the action, though it lacks detail. For conciseness alone, it scores highly as it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive delete operation), lack of annotations, and no output schema, the description is incomplete. It does not address behavioral risks, return values, or error conditions. Sibling tools include other delete operations, but no differentiation is provided. The description fails to compensate for the missing structured data, leaving critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'campaignId' clearly documented as 'ID kampanii' (ID of the campaign). The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usuwa kampanię' (Polish for 'Deletes a campaign') restates the tool name 'fluentcrm_delete_campaign' in a tautological manner. It specifies the verb 'delete' and resource 'campaign' but does not differentiate from sibling tools like 'fluentcrm_delete_contact' or 'fluentcrm_delete_list', which follow the same pattern. This is minimal and lacks specificity beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 mention prerequisites (e.g., needing an existing campaign ID), exclusions, or comparisons to related tools like 'fluentcrm_pause_campaign' or 'fluentcrm_resume_campaign'. Without any context, it fails to help an agent make informed decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('retrieves') without detailing traits like whether it's read-only, paginated, rate-limited, or what the output format is. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single phrase, making it front-loaded and efficient. However, it's under-specified rather than optimally concise, as it lacks necessary details for a tool with parameters and no annotations, slightly reducing its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with no schema descriptions, no annotations, and no output schema, the description is incomplete. It doesn't explain the parameters, behavioral traits, or return values, leaving the agent with insufficient information to use the tool correctly in a complex context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (page and search) with 0% description coverage, meaning they are undocumented. The description adds no information about these parameters, such as what 'page' refers to (e.g., pagination index) or what 'search' filters (e.g., by name or ID). It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Pobiera automatyzacje (funnels)' which translates to 'Retrieves automations (funnels)' in English, providing a clear verb ('retrieves') and resource ('automations/funnels'). However, it doesn't distinguish this from sibling tools like 'fluentcrm_list_campaigns' or 'fluentcrm_list_contacts' beyond the resource type, making the purpose somewhat vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention any specific context, prerequisites, or exclusions, such as whether it's for listing all automations or filtered ones, or how it differs from other list tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a mutation action ('assigns') but doesn't disclose behavioral traits like whether this is idempotent, what permissions are needed, error conditions, or what the tool returns. The description is too minimal for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. However, the Polish description mixed with English tool name creates a minor structural issue, and it could benefit from being front-loaded with more context given the mutation nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after assignment, error scenarios, or relationship to sibling tools. The language inconsistency adds to the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., format of IDs, whether listIds can be empty). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Przypisuje kontakt do listy' (Assigns contact to list) states a clear verb+resource action, but it's in Polish while the tool name is in English, creating potential confusion. It doesn't distinguish from sibling tools like 'fluentcrm_detach_contact_from_list' or explain the relationship to other contact/list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., contact/list must exist), when to choose this over similar tools like 'fluentcrm_update_contact', or what happens if the contact is already on the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Tworzy' (Creates) implies a write operation, the description fails to mention important behavioral aspects: what permissions are required, whether this is idempotent, what happens on failure, or what the response contains. The availability warning adds some context but doesn't address core 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence with a parenthetical note. While this is efficient, the availability warning feels like clutter that doesn't belong in the core description. The structure is front-loaded with the main action, but could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a Smart Link is, what happens after creation, what the tool returns, or how it relates to other Smart Link operations. The availability warning doesn't compensate for these fundamental gaps in understanding the tool's role and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 8 parameters thoroughly in Polish. The description adds no parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage situations where the structured data does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Tworzy nowy Smart Link' (Creates a new Smart Link), which clearly indicates a creation action on a specific resource. However, it doesn't distinguish this tool from other creation tools like fluentcrm_create_contact or fluentcrm_create_campaign, and the parenthetical note about availability adds confusion rather than clarifying purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites, when this tool is appropriate compared to other Smart Link tools (like fluentcrm_update_smart_link or fluentcrm_get_smart_link), or any context about what a 'Smart Link' actually is in the FluentCRM ecosystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action is 'Usuwa' (removes/delete), implying a destructive mutation, but doesn't disclose critical behavioral traits such as whether this is irreversible, requires specific permissions, affects associated contacts, or has side effects. For a deletion tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish ('Usuwa tag z FluentCRM'), which is appropriately concise and front-loaded with the core action. However, it could be more structured by including key details like scope or alternatives, but it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a deletion operation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral risks, return values, error handling, and differentiation from siblings. For a destructive tool, this leaves the agent under-informed about critical usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'tagId' documented as 'ID tagu' (tag ID). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usuwa tag z FluentCRM' (Removes tag from FluentCRM) clearly states the action (removes/delete) and resource (tag), but it's vague about scope and doesn't distinguish from sibling tools like 'fluentcrm_detach_tag_from_contact'. It specifies what it does but lacks detail on whether it deletes the tag entirely or just removes it from a context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'fluentcrm_detach_tag_from_contact' (which removes a tag from a contact) and 'fluentcrm_delete_contact' (which deletes a contact), the description doesn't clarify if this tool permanently deletes a tag from the system or just detaches it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a shortcode, implying a read-only operation that outputs code, but doesn't specify if it's safe, what permissions are needed, if it has side effects (e.g., logging usage), or what the output format looks like (e.g., a string). This leaves significant gaps for an agent to understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish ('Generuje shortcode dla Smart Link'), which translates to 'Generates shortcode for Smart Link'. It's front-loaded and wastes no words, though it could benefit from more detail given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool that generates code-like output), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what a shortcode is, how it's used (e.g., in WordPress), what the output looks like, or any behavioral traits like safety or dependencies. This makes it inadequate for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('slug' and optional 'linkText'). The description doesn't add any meaning beyond the schema, such as explaining what a 'slug' represents or how the shortcode is used. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates a shortcode for a Smart Link, which provides a basic purpose (verb+resource). However, it's vague about what a 'Smart Link' is in this context and doesn't distinguish this tool from sibling tools like 'fluentcrm_create_smart_link' or 'fluentcrm_get_smart_link', leaving ambiguity about its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing an existing Smart Link), exclusions, or how it relates to sibling tools like 'fluentcrm_create_smart_link' for creating links or 'fluentcrm_get_smart_link' for retrieving link details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('retrieves details') without adding any behavioral context. It doesn't mention whether this is a read-only operation, what permissions might be required, potential errors (e.g., if the contact doesn't exist), or the format of returned details. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence ('Pobiera szczegóły konkretnego kontaktu') that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, making it efficient. However, it could be slightly more informative without sacrificing brevity, such as by hinting at the parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't provide enough context for an AI agent to fully understand how to use the tool effectively. For example, it doesn't describe what 'details' are returned, potential error conditions, or how this tool fits into the broader context of contact management with sibling tools. This leaves gaps in understanding the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'subscriberId' fully documented in the schema as 'ID kontaktu' (contact ID). The description doesn't add any meaning beyond this, as it doesn't explain what 'subscriberId' represents or provide additional context. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema already handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Pobiera szczegóły konkretnego kontaktu' translates to 'Retrieves details of a specific contact'), which is clear but basic. It specifies the verb ('retrieves') and resource ('contact details'), but doesn't differentiate from sibling tools like 'fluentcrm_find_contact_by_email' or 'fluentcrm_list_contacts', which also retrieve contact information. The description is not tautological but lacks specificity about what distinguishes this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention that this tool is for retrieving a single contact by ID, as opposed to 'fluentcrm_find_contact_by_email' (which uses email) or 'fluentcrm_list_contacts' (which lists multiple contacts). There's no explicit or implied context for usage, leaving the agent to infer from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'retrieves' implies a read-only operation, it doesn't specify whether this requires authentication, what format the list returns in, whether results are paginated, or any rate limits. The description is too minimal for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with 2 parameters and no output schema, the description is insufficient. It doesn't explain what the parameters do, what format the results come in, or any behavioral constraints. With no annotations and minimal description, this leaves significant gaps for the agent to understand how to properly use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but doesn't mention parameters at all. The tool has 2 parameters (page and search) that are completely undocumented in both schema and description, leaving the agent with no guidance on how to use pagination or search functionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Pobiera listę kampanii email' which translates to 'Retrieves a list of email campaigns' - this clearly indicates the verb (retrieves) and resource (email campaigns). However, it doesn't distinguish this tool from other list tools like fluentcrm_list_contacts or fluentcrm_list_automations beyond specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like fluentcrm_get_contact (for single items) and fluentcrm_list_contacts (for lists of a different resource), there's no indication of when to choose list_campaigns over other list operations or when to use it versus get operations for campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'updates' which implies mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish ('Aktualizuje dane kontaktu'), which is appropriately sized and front-loaded. There's zero waste, making it highly concise and well-structured for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation tool with 4 parameters, low schema coverage (25%), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameter meanings, usage context, and expected outcomes, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25%, with only 'subscriberId' documented. The description adds no parameter semantics beyond the schema—it doesn't explain what 'first_name', 'last_name', or 'phone' represent, their formats, or constraints. This fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualizuje dane kontaktu' (Updates contact data) states the verb 'updates' and resource 'contact data', providing a basic purpose. However, it's vague about what specific data can be updated and doesn't differentiate from sibling tools like 'fluentcrm_update_smart_link' or 'fluentcrm_get_contact'. It's adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention using 'fluentcrm_create_contact' for new contacts or 'fluentcrm_get_contact' to retrieve before updating. The description implies usage for updating existing contacts but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates data, but doesn't describe what happens during validation—such as whether it returns errors, warnings, or a success status, or if it performs side effects like checking database constraints. For a validation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's function. It's appropriately sized and front-loaded with no wasted words, making it easy to understand at a glance despite the language barrier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters with low schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what validation entails, what the output might be (e.g., success/failure, error messages), or how parameters interact. For a validation tool with rich input but poor documentation, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 38%, with only 3 of 8 parameters having descriptions in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, failing to compensate for the coverage gap. It doesn't explain the meaning of parameters like 'apply_tags', 'auto_login', or the arrays, leaving them undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Waliduje dane Smart Link przed utworzeniem' (Polish for 'Validates Smart Link data before creation') states the purpose as validating data, but it's somewhat vague. It specifies the resource (Smart Link data) and timing (before creation), but doesn't clearly distinguish from sibling tools like 'fluentcrm_create_smart_link' beyond the validation aspect. The description is adequate but lacks specificity about what validation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before creation ('przed utworzeniem'), suggesting it should be used prior to 'fluentcrm_create_smart_link'. However, it doesn't provide explicit guidance on when to use this tool versus alternatives, such as whether validation is mandatory or optional, or if there are other validation methods. No exclusions or clear alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits like whether this is a mutation (implied by 'assigns'), what permissions are needed, if it's idempotent, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish with zero waste. It's appropriately sized and front-loaded, though it could benefit from more detail given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or side effects. Given the complexity (tag assignment operation) and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond what's in the schema (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Przypisuje tag do kontaktu' (Assigns tag to contact) states a clear verb+resource action but is vague about scope and doesn't differentiate from sibling tools. It doesn't specify whether this adds tags to existing ones or replaces them, nor does it distinguish from the sibling 'fluentcrm_detach_tag_from_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'fluentcrm_update_contact' or 'fluentcrm_detach_tag_from_contact'. The description implies usage for tag assignment but provides no context about prerequisites, constraints, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('delete') without any details about permissions required, whether the deletion is permanent or reversible, rate limits, error conditions, or what the response looks like. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence in Polish that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context like behavioral traits (e.g., permanence, permissions), usage guidelines, and output expectations. The high schema coverage for parameters is insufficient to compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'listId' documented as 'ID listy' (list ID). The description adds no additional meaning beyond what the schema provides, such as format examples or where to obtain the ID. With high schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usuwa listę z FluentCRM' (Deletes a list from FluentCRM) clearly states the action (delete) and resource (list), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling deletion tools like fluentcrm_delete_campaign or fluentcrm_delete_tag, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing the list ID from fluentcrm_list_lists), consequences (e.g., what happens to contacts in the list), or when not to use it (e.g., for removing contacts from a list instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool deletes a Smart Link, implying a destructive mutation, but doesn't disclose critical behaviors: whether deletion is permanent/reversible, permission requirements, error handling, or side effects. The availability warning adds some context but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but not well-structured. The main action is clear upfront, but the parenthetical note about availability is distracting and reduces clarity. It could be more direct by separating concerns or omitting the speculative note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is inadequate. It lacks details on what happens post-deletion, error cases, or confirmation of success. The availability warning doesn't compensate for missing behavioral context, making it incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'smartLinkId', so the schema fully documents it. The description adds no parameter information, which is acceptable given high coverage and zero parameters needing extra explanation. Baseline 4 applies as it doesn't detract from schema clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usuwa Smart Link' (Deletes Smart Link) states the verb and resource, but it's vague about what a 'Smart Link' is and doesn't distinguish from sibling tools like 'fluentcrm_delete_campaign' or 'fluentcrm_delete_contact'. The parenthetical note about availability adds confusion rather than clarifying purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing an existing Smart Link ID), nor does it reference sibling tools like 'fluentcrm_get_smart_link' for verification or 'fluentcrm_list_smart_links' for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Pobiera listę') but lacks details on permissions, rate limits, pagination, or error handling. The note about potential unavailability adds some context but is vague, failing to fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence stating the purpose, followed by a brief note. It is front-loaded with the main action, though the note about availability could be more precise. Overall, it avoids unnecessary verbosity and is structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list retrieval with two parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage context, leaving gaps that could hinder effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('page' and 'search'). The description does not add any meaning beyond the schema, such as explaining how pagination works or search functionality specifics. According to the rules, with high schema coverage, the baseline score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Pobiera listę Smart Links z FluentCRM') which translates to 'Retrieves a list of Smart Links from FluentCRM', providing a clear verb and resource. However, it does not distinguish this tool from other list tools like fluentcrm_list_automations or fluentcrm_list_campaigns, and includes an ambiguous note about availability ('może nie być dostępne w obecnej wersji'), which 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description mentions potential unavailability but does not specify conditions, prerequisites, or compare it to similar tools like fluentcrm_get_smart_link or fluentcrm_list_contacts, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'retrieves', implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'custom fields' entails (e.g., format, pagination). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Pobiera pola niestandardowe') that directly states the action and resource. It's appropriately sized for a simple tool with no parameters, though it could be more structured (e.g., by specifying context). Every word earns its place, but it's slightly under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks details on what 'custom fields' includes (e.g., types, usage), behavioral context, or return values. For a retrieval tool in a CRM context, this leaves significant gaps for an AI agent to understand its full utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is acceptable since there are none to explain. A baseline of 4 is appropriate as it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pobiera pola niestandardowe' (Polish for 'Retrieves custom fields') states a verb ('retrieves') and resource ('custom fields'), providing a basic purpose. However, it lacks specificity about what type of custom fields (e.g., contact fields, campaign fields) and doesn't distinguish from siblings like 'fluentcrm_list_tags' or 'fluentcrm_list_contacts', which are also retrieval operations. The purpose is clear but vague in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, context (e.g., for configuring contacts or campaigns), or exclusions. With siblings like 'fluentcrm_list_contacts' that might involve custom fields, the description offers no differentiation, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('retrieves') without details on permissions needed, rate limits, data freshness, or response format. This leaves significant gaps for a tool that likely provides aggregated data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish, front-loading the core purpose without unnecessary words. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a dashboard stats tool (likely involving aggregated data), no annotations, and no output schema, the description is incomplete. It lacks details on what statistics are returned, their format, or any behavioral traits, making it inadequate for effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (empty schema). The description doesn't need to add parameter details, so a baseline of 4 is appropriate, as it doesn't contradict or omit any parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pobiera statystyki dashboarda' (Polish for 'Retrieves dashboard statistics') states a clear verb ('retrieves') and resource ('dashboard statistics'), but it's vague about what specific statistics are included. It doesn't differentiate from sibling tools like 'fluentcrm_list_campaigns' or 'fluentcrm_list_contacts' beyond the general 'dashboard' focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description doesn't mention any context, prerequisites, or exclusions, such as whether it's for high-level overviews versus detailed reports available in other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'creates' which implies a write operation, but doesn't cover critical aspects like permissions required, whether the campaign starts immediately or needs activation, what happens on failure, or if there are rate limits. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the essential information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation (e.g., returns a campaign ID, starts sending emails), doesn't mention dependencies on other tools (like needing existing templates or lists), and provides no behavioral context. For a tool that creates email campaigns—a potentially complex operation—more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 4 parameters well-documented in the input schema (title, subject, template_id, recipient_list). The description adds no additional parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tworzy nową kampanię email' (Creates a new email campaign) clearly states the verb 'creates' and the resource 'email campaign', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'fluentcrm_create_automation' or 'fluentcrm_create_email_template', which also create different resources in the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing existing templates or lists), exclusions, or relationships with sibling tools like 'fluentcrm_list_campaigns' or 'fluentcrm_delete_campaign'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a creation operation, implying mutation, but doesn't describe what happens on success/failure, whether duplicates are allowed, what permissions are required, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core action, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns a contact ID, triggers automations), error conditions, or how it integrates with sibling tools. Given the complexity of contact creation in a CRM context, more behavioral and contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the input schema, which has 100% coverage with clear descriptions for all 7 parameters. The baseline is 3 since the schema does the heavy lifting, but the description doesn't provide additional context like format requirements (e.g., email validation) or default behaviors for optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tworzy nowy kontakt' - Creates a new contact) and the resource ('w FluentCRM' - in FluentCRM), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'fluentcrm_update_contact' beyond the basic create vs. update distinction, missing an opportunity to clarify when to create versus update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., whether the contact must not already exist), when to use 'fluentcrm_update_contact' instead for existing contacts, or how it relates to other sibling tools like 'fluentcrm_attach_contact_to_list' for post-creation actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'creates' without disclosing behavioral traits. It doesn't mention permissions needed, whether creation is idempotent, what happens on duplicate titles, or what the response contains. For a creation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's purpose with zero wasted words. It's appropriately front-loaded and perfectly concise for its simple function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, whether the template becomes immediately available, what format the body should be in beyond 'HTML', or how this interacts with other FluentCRM components. The context demands more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters (title, subject, body) with Polish descriptions. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tworzy nowy szablon email' (Creates a new email template) clearly states the action (creates) and resource (email template) in Polish. It's specific enough to understand the basic function, though it doesn't explicitly differentiate from sibling tools like 'fluentcrm_create_campaign' or 'fluentcrm_create_automation' which also create resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites, when email templates are needed, or how this relates to sibling tools like 'fluentcrm_list_email_templates' or 'fluentcrm_create_campaign'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Tworzy nową listę' implies a write/mutation operation, the description doesn't disclose any behavioral traits such as required permissions, whether the operation is idempotent, what happens on duplicate titles/slugs, error conditions, or what the response contains. This leaves significant gaps for an agent to understand how to use this tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words or structural issues. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool (creates a new list) with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, error handling, or response format, nor does it provide usage context relative to sibling tools. The 100% schema coverage helps with parameters, but other critical information is missing for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters (title, slug, description) clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tworzy nową listę' - Creates a new list) and the resource ('w FluentCRM' - in FluentCRM), which is specific and unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'fluentcrm_list_lists' or 'fluentcrm_delete_list', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple sibling tools for managing lists (e.g., list_lists, delete_list), but the description doesn't mention any prerequisites, constraints, or when this creation tool is appropriate compared to other list-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it creates a new tag, implying a write operation, but doesn't disclose behavioral traits like whether it requires authentication, what happens on duplicate tag names (e.g., error or update), rate limits, or what the return value might be (e.g., tag ID or success confirmation). This leaves significant gaps for an agent to use it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish ('Tworzy nowy tag w FluentCRM') that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error handling, or return values, which are crucial for an agent to invoke this tool effectively in a real-world context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (title, slug, description) well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tworzy nowy tag w FluentCRM' clearly states the action ('tworzy' - creates) and resource ('nowy tag' - new tag) in FluentCRM. It's specific about creating a tag rather than listing or deleting tags, but it doesn't explicitly differentiate from sibling tools like fluentcrm_delete_tag or fluentcrm_list_tags beyond the verb choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing admin permissions), when not to use it (e.g., if a tag already exists), or refer to related tools like fluentcrm_list_tags for checking existing tags or fluentcrm_attach_tag_to_contact for applying tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Usuwa' clearly indicates a destructive operation, the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, affects related data (e.g., lists, tags), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's function without unnecessary words. It's appropriately sized for a simple deletion tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion (success response, error conditions), whether the action affects other entities, or any behavioral constraints. The combination of destructive nature and lack of structured metadata requires more comprehensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'subscriberId' clearly documented as 'ID kontaktu do usunięcia' (ID of contact to delete). The description doesn't add any additional parameter information beyond what's in the schema, but with complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Usuwa' - removes/deletes) and the resource ('kontakt z FluentCRM' - contact from FluentCRM). It distinguishes itself from sibling tools like fluentcrm_update_contact or fluentcrm_get_contact by specifying deletion, but doesn't explicitly differentiate from other deletion tools like fluentcrm_delete_campaign or fluentcrm_delete_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a valid subscriberId), consequences of deletion, or when to choose this over other contact management tools like fluentcrm_update_contact or fluentcrm_detach_contact_from_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('usuwa' - removes) but doesn't disclose behavioral traits like whether this is a destructive operation (likely yes, but not confirmed), permission requirements, error handling (e.g., if contact/list doesn't exist), or side effects (e.g., impact on automation triggers). The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence ('Usuwa kontakt z listy') that directly states the purpose without unnecessary words. It's appropriately sized for a simple operation, though it could be slightly more informative without losing conciseness. No structural issues are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., destructiveness, error cases), usage context, and what to expect upon success or failure. For a tool that modifies data, this minimal description leaves significant gaps for an AI agent to understand its full implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('subscriberId' and 'listIds') clearly documented in the schema. The description doesn't add any meaning beyond the schema (e.g., it doesn't explain parameter relationships or usage examples). With high schema coverage, the baseline score of 3 is appropriate as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usuwa kontakt z listy' (Removes contact from list) clearly states the action (remove/usuwa) and target (contact from list). It distinguishes from sibling tools like 'fluentcrm_attach_contact_to_list' by specifying removal rather than addition. However, it doesn't explicitly mention the resource (FluentCRM) or differentiate from 'fluentcrm_detach_tag_from_contact' beyond the list vs. tag distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., contact must exist, list must exist), when not to use it (e.g., for bulk operations), or direct comparisons to siblings like 'fluentcrm_delete_contact' (which removes entirely) or 'fluentcrm_update_contact' (which might modify list membership).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a destructive mutation, requires specific permissions, has side effects (e.g., triggering automations), or what happens on success/failure (e.g., returns confirmation or error).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Polish that directly states the tool's action. It's front-loaded with no unnecessary words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as behavioral traits (e.g., idempotency, error handling), usage prerequisites, and what to expect upon execution, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in Polish ('ID kontaktu' for subscriberId, 'Lista ID tagów' for tagIds). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate as the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usuwa tag z kontaktu' (Removes tag from contact) clearly states the verb (removes) and resource (tag from contact), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'fluentcrm_detach_contact_from_list', which has a similar detach operation but for lists rather than tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., the contact and tag must exist), contrast with 'fluentcrm_attach_tag_to_contact', or specify error conditions like invalid IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is a search, implying a read-only operation, but does not specify whether it returns a single contact or multiple matches, error handling for non-existent emails, authentication requirements, or rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's purpose. It is front-loaded with the core action and criterion, with no redundant words or unnecessary elaboration. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search operation with one parameter) and the absence of annotations and output schema, the description is incomplete. It does not explain what is returned (e.g., contact details, null if not found), potential errors, or usage constraints. For a tool with no structured behavioral data, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'email' parameter documented as 'Adres email' (Email address). The description adds no additional meaning beyond this, as it only restates the parameter's purpose. According to the rules, with high schema coverage (>80%), the baseline score is 3 even without extra param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wyszukuje kontakt po adresie email' (Searches for a contact by email address) clearly states the verb 'wyszukuje' (searches) and the resource 'kontakt' (contact), with the specific criterion 'po adresie email' (by email address). It distinguishes from siblings like 'fluentcrm_get_contact' (which might use an ID) and 'fluentcrm_list_contacts' (which lists multiple contacts), but does not explicitly name these alternatives. It is specific and actionable, though not fully differentiated from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mention scenarios like searching by email instead of ID, or when to prefer this over list operations. Without any context or exclusions, the agent must infer usage from the name and description alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Pobiera' - retrieves) but doesn't disclose behavioral traits such as whether this is a read-only operation, what permissions are required, error handling, or the format of returned details. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, potential errors, or usage context. For a tool that retrieves specific data, more information on the response format and behavioral aspects would be necessary for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'smartLinkId' clearly documented as 'ID Smart Link'. The description adds no additional meaning beyond this, as it doesn't explain what a Smart Link ID is, where to find it, or its format. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Pobiera' - retrieves/fetches) and resource ('szczegóły konkretnego Smart Link' - details of a specific Smart Link), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'fluentcrm_list_smart_links' or 'fluentcrm_update_smart_link' beyond the 'specific' aspect, which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description mentions 'specific Smart Link' but doesn't clarify if this is for viewing details after listing, editing, or other contexts. There's no mention of prerequisites, alternatives like 'fluentcrm_list_smart_links', or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior beyond parameters, or what format the returned list takes. For a list operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list retrieval tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the returned data looks like, how pagination works beyond parameter names, or any constraints on the search functionality. The agent would need to guess about the response format and behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters with their purposes. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pobiera' - retrieves) and resource ('listę wszystkich kontaktów z FluentCRM'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'fluentcrm_find_contact_by_email' or 'fluentcrm_get_contact', which suggests it retrieves all contacts rather than specific ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description doesn't mention when to choose this over 'fluentcrm_find_contact_by_email' for email searches or 'fluentcrm_get_contact' for single contact retrieval, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a retrieval operation ('Pobiera'), implying it's read-only, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a list tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is minimal but inadequate. It lacks behavioral context (e.g., output format, pagination), usage guidelines, and doesn't compensate for the absence of annotations. For a list tool with no output schema, more detail on what is returned would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters ('page' and 'search') with descriptions. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter usage, default values, or interactions. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pobiera' - retrieves) and resource ('wszystkie tagi z FluentCRM' - all tags from FluentCRM). It distinguishes this as a read operation for tags, which differentiates it from sibling tools like fluentcrm_create_tag or fluentcrm_delete_tag. However, it doesn't explicitly contrast with other list tools (e.g., fluentcrm_list_contacts) beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention when to prefer this over other tag-related tools (like fluentcrm_create_tag) or other list operations. There's no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Retrieves' implies a read-only operation, but it doesn't specify whether this returns all templates, supports pagination, includes metadata, or has any access restrictions. For a list tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Pobiera szablony email') that directly states the purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks depth. It doesn't explain what 'retrieves' entails (e.g., format, scope, or limitations), which could be important for a list operation. For a basic read tool, it's functional but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain any parameters, so it meets the baseline of 4 for zero-parameter tools, as there's no additional semantic burden to cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pobiera szablony email' (Polish for 'Retrieves email templates') clearly states the verb 'retrieves' and the resource 'email templates', which is specific and actionable. However, it doesn't distinguish this tool from sibling list tools like fluentcrm_list_automations or fluentcrm_list_campaigns, which follow a similar pattern but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites (e.g., needing email templates to exist), exclusions, or comparisons to other list tools in the sibling set, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it retrieves all lists but doesn't mention any behavioral traits like pagination, rate limits, authentication requirements, error conditions, or what 'all lists' entails (e.g., active/inactive, count limits). This leaves significant gaps for an agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Polish that directly states the tool's purpose without any unnecessary words or structural fluff. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate but incomplete. It states what the tool does but lacks behavioral context (e.g., return format, limitations) that would help an agent use it effectively. For a read-only list operation, more detail on output expectations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it correctly doesn't mention any parameters, aligning with the schema. A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pobiera' meaning 'Retrieves' or 'Gets') and the resource ('wszystkie listy z FluentCRM' meaning 'all lists from FluentCRM'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'fluentcrm_list_contacts' or 'fluentcrm_list_tags', which follow the same pattern for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, when this tool is appropriate compared to other list-related tools (like 'fluentcrm_create_list' or 'fluentcrm_delete_list'), or any contextual constraints for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fluentcrm-mcp-server MCP server](https://glama.ai/mcp/servers/netflyapp/fluentcrm-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/netflyapp/fluentcrm-mcp-server)

Score Badge

Copy to your README.md:

[![fluentcrm-mcp-server MCP server](https://glama.ai/mcp/servers/netflyapp/fluentcrm-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/netflyapp/fluentcrm-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/netflyapp/fluentcrm-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server