connectif-mcp

by Yoryoboy

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool is clearly scoped to a distinct Connectif resource (contacts, purchases, products, etc.), so there is no overlap in target entities. An agent can easily choose the correct tool based on the resource name.
Naming Consistency5/5
All tools follow the exact same pattern of `connectif_<resource>`, with consistent lowercase and underscore separation. This makes the naming perfectly predictable and easy to navigate.
Tool Count5/5
The 12 tools cover the primary Connectif resource types (contacts, purchases, products, workflows, etc.) without being excessive. This falls comfortably within the well-scoped range for a domain-specific server.
Completeness4/5
The tool set covers core resources like contacts, purchases, products, and workflows, but the generic nature of each tool (requiring an 'action' parameter) obscures detailed operations. Some potentially important resources like campaigns or segments are missing, but the main lifecycle is represented.
Average 1.8/5 across 12 of 12 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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
This repository is licensed under MIT License.
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 burden is entirely on the description. The text does not disclose side effects, permission requirements, rate limits, return format, or any operational details. The agent is left completely in the dark about what execution entails.
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?
The text is extremely short, but brevity here is under-specification, not efficiency. Every sentence is vague and adds no actionable information, so the 'conciseness' is not a positive trait.
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?
With no annotations, no output schema, and an empty input schema, the description is expected to carry all contextual information. It fails to explain what the tool does, when to use it, or what to expect, making it completely inadequate for agent decision-making.
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?
The input schema is empty, so the description must compensate, but it instead references an 'action' parameter that is absent from the schema. This is misleading and provides no meaningful semantic information about parameters or inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Direct Connectif API operations for imports' provides no specific verb or resource, and the instruction to 'Use action to select an official operation' references a parameter that does not exist in the schema. It fails to distinguish the tool from its siblings since it does not state what concrete task it performs.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, making it impossible for an agent to decide when to invoke 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 full responsibility for disclosing behavior. It reveals nothing about side effects, permissions, request/response format, or error behavior. The mention of 'action' conflicts with the empty schema, creating confusion rather than transparency.
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?
The description is short, but the first sentence is generic boilerplate, and the second sentence adds a misleading directive. Conciseness requires clarity, not just brevity; this text does not earn its place.
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 has no schema parameters, no output schema, and appears among many similar siblings, the description is wholly inadequate. It fails to explain what the tool does, how to invoke a specific operation, or what results to expect.
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?
The input schema has zero parameters, and description coverage is vacuously 100%. However, the description references an 'action' parameter that does not exist in the schema, actively misleading the agent. This is worse than providing no parameter info.
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 phrase 'Direct Connectif API operations' is generic and does not specify a concrete action (e.g., list, update, delete). 'for contact_fields' names the resource, but the siblings (connectif_contacts, connectif_purchases, etc.) follow the same pattern, so this description does not distinguish the tool. The instruction 'Use action to select an official operation' hints at a wrapper but does not clarify the actual 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?
There is no guidance on when to use this tool vs. its siblings. No context, prerequisites, or alternatives are mentioned. The vague 'Use action' line is not actionable because the schema has no 'action' parameter.
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 must disclose side effects, required permissions, rate limits, or return patterns. It provides none of these. The mention of 'direct API operations' implies a passthrough but does not clarify whether operations are destructive, reversible, or what responses look like.
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?
The description is only two short sentences, which is concise, but the content is under-specified. The first sentence is a tautology, and the second is vague. It lacks structure or front-loading of the most critical information.
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 no annotations, no output schema, and an empty input schema, the description fails to provide essential context. The agent cannot infer what operations are available, what inputs are needed, what outputs to expect, or how this tool relates to the broader API. This is entirely inadequate for a tool with this complexity.
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?
The input schema defines zero parameters, yet the description explicitly references an 'action' parameter. This creates a contradiction and leaves the agent without any schema-based meaning. The description adds no useful semantics and actively misleads by referencing an undocumented property.
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 'Direct Connectif API operations for custom_event_types' only restates the resource and says it's API operations, without specifying a verb or concrete function. 'Use action to select an official operation' suggests multiple sub-operations but never names them, so it remains vague and does not distinguish from sibling tools like connectif_custom_events.
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 given on when to use this tool versus alternatives. The description does not mention any prerequisites, scenarios, or exclusions. The only instruction 'Use action to select an official operation' is unclear without further 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, the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, rate limits, data scope, or any operational consequences. 'Direct API operations' is too broad to be informative, and the reference to 'action' without schema validation is misleading.
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?
The description is short, but brevity is not conciseness when it sacrifices all substance. The first sentence is essentially a restatement of the tool name, and the second sentence is an unhelpful directive. It is under-specified rather than appropriately sized.
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 that there is no output schema, no annotations, and an empty input schema, the description needed to provide operational context. It fails to explain what export operations are available, how 'action' maps to them, or what the tool returns. It is completely inadequate for an agent to use the tool correctly.
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?
The schema has zero parameters, yet the description instructs the agent to 'Use action to select an official operation,' implying a parameter that does not exist in the input schema. This contradiction creates confusion rather than adding meaning. The description does not compensate for the empty schema; it introduces an undocumented phantom parameter.
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 says 'operations for exports,' which is vague and lacks a specific verb or resource scope. It does not clearly differentiate from the many sibling Connectif tools, and 'use action' is a generic placeholder rather than a concrete capability.
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 only guidance is 'Use action to select an official operation,' which hints at a selection mechanism but provides no context for when to use this tool versus siblings, no prerequisites, and no exclusions. The absence of schema support for 'action' further weakens the guidance.
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 responsibility for disclosing behavior. The description gives no indication of side effects, mutability, required permissions, or whether operations are read-only. 'Operations' could include destructive actions, but this is not disclosed, leaving the agent without essential safety information.
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?
The description is only two sentences, which is concise, but it is under-specified rather than efficiently informative. It omits critical details and leaves the agent guessing about the tool's usage, making the brevity a drawback rather than a strength.
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?
With an empty input schema, no output schema, no annotations, and a vague description, the tool is critically under-documented. The description fails to explain what 'official operations' are available, what inputs are expected, what outputs are produced, or any constraints. This is completely inadequate for a tool that appears to be a multi-operation dispatcher.
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?
The input schema lists zero properties, yet the description explicitly instructs to 'Use action to select an official operation.' This introduces a parameter that is not defined in the schema, which is misleading and breaks the contract between description and schema. The agent cannot know what values 'action' accepts or how to provide it.
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 states 'Direct Connectif API operations for products' which identifies the resource but is vague about the specific operations. 'Use action to select an official operation' implies a generic dispatcher, but without listing operations it fails to clearly distinguish from sibling tools like connectif_contacts or connectif_purchases.
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?
There is no explicit guidance on when to use this tool versus alternatives. The only instruction is 'Use action to select an official operation,' which is a mechanism hint, not a usage guideline. It does not mention prerequisites, exclusions, or scenarios where sibling tools would be more appropriate.
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 responsibility for behavioral disclosure. It does not state whether operations are read-only, mutating, require authentication, or have side effects. 'Direct API operations' is too generic to convey meaningful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, conciseness without substance is not beneficial—the content is nearly tautological and does not earn its place by adding useful information.
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 no output schema, no annotations, and an empty input schema, the description is utterly incomplete. It does not explain what operations are possible, how the action is specified, or what returns. The reference to an undocumented 'action' further compounds the incompleteness.
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?
The input schema is empty with 0 parameters, so there is nothing to document. However, the description misleadingly instructs to 'Use action to select an official operation,' implying a parameter that does not exist in the schema. This directly miscommunicates the tool's interface.
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 'Direct Connectif API operations for contacts' is vague—it identifies the resource (contacts) but provides no specific verb or operation. 'Use action to select an official operation' implies a selector but doesn't specify what operations are available. It fails to distinguish clearly from sibling tools beyond the contacts domain.
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 given on when to use this tool versus alternatives like connectif_purchases or connectif_contact_fields. The mention of 'action' suggests some selection mechanism but does not explain appropriate contexts, prerequisites, or exclusions.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Direct Connectif API operations' and mentions an 'action' selector, but it does not explain side effects, authentication, rate limits, or what the operation does. Critically, it references an 'action' parameter that is not present in the input schema, making the tool appear inconsistent.
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 two short sentences with no redundant words. It is front-loaded with the resource name and provides a clear instruction to use 'action.' While it is under-specified, that is a completeness issue, not a conciseness issue—it is efficient and to the point.
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?
The tool has no annotations, no output schema, and an empty input schema, so the description is the sole source of contextual information. It does not enumerate the operations available, provide examples, explain return values, or cover error cases. It is far too minimal to be genuinely useful in selecting and invoking the tool.
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 zero properties, giving a baseline of 4. The description introduces an 'action' parameter that is not in the schema, adding some meaning but without enumerating possible values. This inconsistency reduces the value provided, as the parameter is undefined and the schema doesn't support it.
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 says 'Direct Connectif API operations for custom_events,' which is essentially a restatement of the tool name with a generic word 'operations.' It identifies the resource (custom_events) but fails to specify what concrete actions are performed. Mentioning 'Use action to select an official operation' is vague and doesn't clarify the tool's 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 is provided on when to use this tool versus its siblings. The description does not mention alternatives or exclusions, and the only hint is the resource name 'custom_events.' It does not provide context about when this tool is appropriate or when another connectif_* tool would be better.
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 mentions 'Direct Connectif API operations' which implies low-level API access, but does not disclose authentication requirements, mutation vs. read operations, rate limits, or effects. No behavioral traits are revealed beyond the vague 'direct' label.
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 concise with only two sentences and gets to the point quickly. However, the second sentence introduces a non-existent parameter, making it not entirely earning its place. It is compact but not well-structured given the misinformation.
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?
The tool has no annotations, no output schema, and only a vague description. It lacks any information about available operations, how to invoke them, return values, or error handling. The description is completely inadequate for an agent to understand and use the tool safely.
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?
The input schema is empty with zero parameters, so the baseline should be 4. However, the description instructs to 'Use action to select an official operation', introducing an 'action' parameter that does not exist in the schema. This is misleading and actively harms parameter understanding, warranting a score of 1.
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 identifies the resource as 'purchases' and states it performs 'Direct Connectif API operations', but the verb 'operations' is vague and doesn't specify what exact actions are available. It distinguishes from siblings by resource, but lacks clarity on what the tool actually does beyond being a generic proxy.
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 only hint is that it's for purchases, but there is no explicit context, exclusions, or mention of sibling tools like connectif_contacts or connectif_products. The statement 'Use action to select an official operation' does not clarify usage scenarios.
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 and this minimal description, the agent has no information about side effects, authorization requirements, rate limits, or response behavior. The phrase 'Direct operations' does not convey whether this is a read-only or mutating tool. This is a significant gap for a tool that may perform various operations.
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 concise at two sentences, but the second sentence is vague and does not earn its place. It is under-specified rather than effectively brief, providing too little detail to be useful.
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 absence of annotations, output schema, and defined parameters, the description is severely incomplete. It does not explain what operations exist, what the tool returns, or what 'store' specifically covers. The agent is left with no clear way to invoke or understand this tool among many siblings.
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 zero parameters, yet the description says 'Use action to select an official operation', which implies an 'action' field that is not present in the schema. This inconsistency confuses rather than clarifies. The description adds no meaningful parameter semantics and even misleads about expected inputs.
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 it provides 'Direct Connectif API operations for store', which identifies the resource (store) and implies a set of operations. However, it does not enumerate which operations are available, and 'Use action to select an official operation' is vague. It only loosely distinguishes from sibling tools by 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?
There is no guidance on when to use this tool versus sibling tools like connectif_contacts or connectif_products. The only instruction is to use an 'action' parameter, which is not defined in the schema. No alternatives, exclusions, or prerequisites are mentioned.
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 must disclose behavioral traits, but it only states 'Direct Connectif API operations' without addressing safety, side effects, permissions, rate limits, or return behavior. The phrase 'Use action to select an official operation' does not reveal what the tool actually does or its consequences, leaving the agent completely uninformed about potential mutations or read-only nature.
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 two short sentences with no fluff. It is front-loaded with the resource name and provides a brief usage hint. While under-specified, the structure is concise and would score higher if the content were more informative.
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?
This tool has an empty schema, no output schema, and no annotations, so the description is the sole source of information. It fails to explain what operations are available, how the 'action' selector works, or what the tool returns. Sibling tools cover many other resources, and an agent cannot select or invoke this tool correctly without additional context. This is completely inadequate for a functional tool.
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 zero parameters (100% coverage trivially), so per the rubric the baseline is 4. The description mentions 'action' but does not define it as a schema parameter, which is a minor inconsistency. However, since there are no parameters to document, the description does not need to add further parameter meaning, though the 'action' reference is unexplained.
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 'Direct Connectif API operations for coupon_sets' essentially restates the tool's name and resource without a specific verb or action (e.g., list, create, update). 'Use action to select an official operation' hints at a generic proxy but does not clarify what operations are available, making the purpose vague and nearly tautological.
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 sibling tools like connectif_contacts or connectif_products. The instruction 'Use action to select an official operation' is an internal usage step, not a contextual recommendation. There is no mention of alternatives, exclusions, or prerequisites.
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 present, so the description carries full responsibility. It discloses no side effects, authentication needs, or operational details. The tool merely says it performs 'direct API operations,' which gives no behavioral insight.
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 brief at two sentences, with no redundant filler. However, brevity is achieved at the expense of substance; it's under-specified rather than efficiently informative.
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?
With no annotations, no output schema, and no parameters, the description leaves the agent without enough information to know what operations are available, what inputs are expected, or what results to expect. It fails to enable correct 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?
The input schema has zero parameters, but the description references an 'action' selector, implying an undocumented parameter. This confusingly contradicts the schema's empty parameter list, adding confusion rather than clarifying semantics.
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 identifies this as a tool for 'Connectif API operations for workflows,' conveying a resource area (workflows) but no specific verb or operation type. It distinguishes itself from sibling tools by the 'workflows' scope, but remains vague about what the tool actually does.
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 prefer this tool over sibling tools. The phrase 'Use action to select an official operation' suggests an invocation detail but does not frame it as a decision between alternatives.
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 must disclose behavior on its own. It only hints at 'direct' API operations and an 'action' selector, but doesn't mention side effects, permissions, rate limits, or return values.
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?
Two sentences, short and to the point. However, it's under-specified; the 'action' parameter is mentioned but not explained, so brevity comes at the cost of completeness.
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?
With zero parameters, no annotations, and no output schema, the description is the only source of context. It fails to explain what operations are available, how the 'action' parameter works, or what the tool returns, leaving the agent without essential guidance.
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 is empty, so baseline is 4, but the description introduces an 'action' parameter that isn't in the schema. It adds some meaning (action selects operation) but doesn't explain value formats or options, so it falls short of the baseline.
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 names the resource 'custom_integrations' but uses the vague verb 'operations' without specifying a concrete action. It distinguishes from siblings by resource name but lacks a clear 'what it does' statement.
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?
It mentions 'Use action to select an official operation' but provides no guidance on when to use this tool versus the many sibling connectif_* tools. No context, prerequisites, or exclusions are given.
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:

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

Score Badge

Copy to your README.md:

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

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/Yoryoboy/connectif-mcp'

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