Skip to main content
Glama

Weav Customer Service

by io.github.dubdubdubco

Server Details

Explore Weav customer service pricing, features, comparisons, signup, and demos. No auth required.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Available Tools

6 tools
get_comparisonAInspect

Return a short structured contrast of Weav vs Ada, Intercom, and Zendesk, plus the comparison page URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesDescribe the user's underlying goal in one sentence — not the tool you're calling.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. The verb 'Return' makes the read-only, non-mutating nature reasonably clear, and it describes the output shape. However, it does not disclose any limitations, error cases, or additional behaviors beyond the basic return value.

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, information-dense sentence that front-loads the action and includes the essential details: the compared products and the URL output. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, all parameters are fully described in the schema, and the description gives a clear high-level account of the returned content. Since there is no output schema, a slightly more detailed return shape would be ideal, but the description is sufficient for correct invocation and basic use.

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 baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides; it does not explain how context, llm_model, or conversation_id affect the call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and identifies the exact resource: a contrast of Weav vs Ada, Intercom, and Zendesk, plus the comparison page URL. It clearly distinguishes this tool from siblings like get_product_overview or get_pricing, which cover different content.

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 does not state when to use this tool versus alternatives, or mention any exclusions or prerequisites. Usage is only implied by the tool name and the mention of a comparison resource; there is no explicit routing or alternative guidance.

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

get_demoAInspect

Return the sales/demo booking URL (weav.com/sales). Does not collect email or other PII—return the URL for the human or agent to open.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesDescribe the user's underlying goal in one sentence — not the tool you're calling.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds a valuable guarantee that no email/PII is collected and instructs returning the URL for a human or agent to open, which is meaningful side-effect 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?

A single, front-loaded sentence states the action and exact URL, followed by a high-value behavioral note about PII. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple URL-return tool with fully documented parameters and no output schema, the description covers purpose and side effects well. It could explicitly note that the required parameters serve analytics/tracing, but the schema already explains them.

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 all three parameters are fully documented in the schema. The description adds no parameter-specific meaning beyond clarifying the tool returns a URL rather than performing a booking.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns the sales/demo booking URL at weav.com/sales. The exact URL and tool name make it clearly distinct from siblings like get_pricing or get_signup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use when the user wants a sales/demo booking link, but does not explicitly name alternatives or state when not to use this tool. Sibling differentiation is left largely to the agent's interpretation of the names.

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

get_more_toolsA
Read-onlyIdempotent
Inspect

Check for additional tools whenever your task might benefit from specialized capabilities - even if existing tools could work as a fallback.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesA description of your goal and what kind of tool would help accomplish it.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is well covered. The description adds useful context about when to check for more tools but does not describe what happens after the call or what form the additional tools take. This is acceptable given the strong 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, front-loaded sentence. It leads with the action ('Check for additional tools') and then gives a clear condition, with no redundant or wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple meta-tool with well-documented parameters and safety annotations, the description is largely complete. The main gap is the lack of any statement about the return value or how the discovered tools are presented, but since there is no output schema, a brief clarification would have made it fully complete.

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 both required parameters are already fully documented. The description reinforces the purpose of the 'context' parameter but adds no additional parameter-level meaning beyond the schema, so 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Check') and a clear resource ('additional tools'), and the purpose—discovering specialized tools—is immediately apparent. It also inherently distinguishes itself from sibling get_* tools by being a meta-tool that retrieves tools rather than product information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit trigger condition: use it whenever the task might benefit from specialized capabilities, even if existing tools could work as a fallback. It does not list when-not-to-use cases or name alternative tools, so it stops short of a full 5.

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

get_pricingAInspect

Return Weav public pricing: Lite, Plus, Pro, Max monthly prices, annual discount, add-ons, and signup/sales links. Use this instead of scraping weav.com/pricing.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesDescribe the user's underlying goal in one sentence — not the tool you're calling.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It signals a read-only operation via 'Return' and states the data is public pricing, implying no special auth or destructive side effects. It also positions the tool as the sanctioned replacement for scraping, which usefully sets expectations about reliability, though it does not mention caching or data freshness.

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 two sentences with no wasted words. The first sentence front-loads the return contents, and the second sentence gives direct usage guidance. Everything present earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description enumerates the key return fields, giving the agent a clear idea of what the response will contain. It omits minor details such as currency or regional applicability, but for the stated scope and low complexity, the description is sufficiently complete.

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%, and each parameter (context, llm_model, conversation_id) already has a detailed description in the input schema. The tool description adds no per-parameter semantics, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and a clear resource ('Weav public pricing'), then enumerates the exact contents: Lite, Plus, Pro, Max monthly prices, annual discount, add-ons, and links. This makes the tool's scope unambiguous and distinguishes it from siblings like get_comparison and get_product_overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool instead of scraping weav.com/pricing, which provides clear, actionable usage guidance. It does not explicitly address sibling tools like get_comparison or get_demo, but the pricing-specific content list makes the intended use case evident.

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

get_product_overviewAInspect

Return a structured overview of Weav: AI agents, unified inbox, channels, training, actions, and escalation. Links to product and docs.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesDescribe the user's underlying goal in one sentence — not the tool you're calling.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are present, so the description carries the burden. It does disclose the response type (structured overview) and the presence of product/docs links, which is useful. However, it does not explicitly state read-only behavior, absence of side effects, or any output format details beyond 'structured'.

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 sentence with no filler. It front-loads the core purpose, gives a compact topic list, and ends with the link outcome. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple informational retrieval tool with no output schema and no annotations, the description is reasonably complete: it names the content areas and the returned links. It could add sibling differentiation, but that gap is already reflected in usage_guidelines.

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 all three parameters are already documented in the schema. The description adds no parameter-level detail, but it does not need to; the high coverage supports the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Return a structured overview of Weav', and enumerates the included topics (AI agents, unified inbox, channels, training, actions, escalation). This clearly differentiates it from sibling tools named for comparison, pricing, demo, signup, or 'more tools'.

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 about when to use this tool versus alternatives like get_comparison or get_pricing. The description implies an overview request from the name and content, but offers no conditions, exclusions, or routing hints.

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

get_signupAInspect

Return the self-serve signup URL (app.weav.com/register) and what the free Lite start includes.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesDescribe the user's underlying goal in one sentence — not the tool you're calling.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4/5.0
Behavior4/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. The verb 'Return' and the explicit content description make clear this is a read-only informational operation with no side effects. It also specifies the exact URL and the scope of what is included, providing good behavioral transparency for a simple lookup tool.

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?

A single sentence that is front-loaded with the core action and result, with no wasted words. It efficiently conveys the tool's purpose and the exact URL while mentioning the additional information returned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, a fully described schema, and no output schema, the description adequately covers what the agent should expect: the signup URL and a summary of the free Lite start. It could be slightly more detailed about what 'includes' means, but for a simple informational tool this is complete enough.

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?

All three parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema, but none is needed because the schema already documents context, llm_model, and conversation_id adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' a specific resource (the self-serve signup URL app.weav.com/register) and the additional content (what the free Lite start includes). This distinguishes it from sibling tools like get_demo or get_pricing, whose purposes are different.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: when a user wants to sign up or learn about the free Lite plan, this tool is appropriate. However, it does not explicitly mention alternatives or provide exclusion criteria such as 'use get_demo for a guided demo' or 'use get_pricing for paid plans'.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updates
    • Changedget_comparison4 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Describe the user's underlying goal in one sentence — not the tool you're calling.",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context",
+  "llm_model"
+]
    • Changedget_demo4 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Describe the user's underlying goal in one sentence — not the tool you're calling.",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context",
+  "llm_model"
+]
    • Addedget_more_tools
    • Changedget_pricing4 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Describe the user's underlying goal in one sentence — not the tool you're calling.",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context",
+  "llm_model"
+]
    • Changedget_product_overview4 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Describe the user's underlying goal in one sentence — not the tool you're calling.",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context",
+  "llm_model"
+]
    • Changedget_signup4 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Describe the user's underlying goal in one sentence — not the tool you're calling.",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context",
+  "llm_model"
+]
  2. 5 tool updates
    • First observedget_comparison
    • First observedget_demo
    • First observedget_pricing
    • First observedget_product_overview
    • First observedget_signup

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool maps to a distinct purpose: comparison, demo, pricing, product overview, signup, and tool discovery. There is no meaningful overlap between them, so an agent should rarely confuse one for another.

Naming Consistency5/5

All tool names follow the same get_<noun> convention, using clear lowercase with underscores. This is consistent and predictable across the entire set.

Tool Count5/5

Six tools is a well-scoped size for a customer-service/sales information server. Each tool covers one necessary action without requiring a large or redundant surface.

Completeness5/5

The set covers the full customer journey from understanding the product and pricing to comparing, booking a demo, and signing up. Product overview and comparison also link to deeper resources, so there are no obvious dead ends.

Resources