Skip to main content
Glama
andrewconnell

senja-mcp

by andrewconnell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP Server for Senja (unofficial)

Collect, Manage and Share Testimonials - The easiest way to collect testimonials and add them to your website. Get started for free.

@andrewconnell/senja-mcp@next @andrewconnell/senja-mcp@latest @andrewconnell/senja-mcp@next

An MCP (Model Context Protocol) server for the Senja testimonial API. This server allows AI assistants like Claude to interact with your Senja testimonials through standardized MCP tools.

Features

  • List testimonials with filtering by approval status, rating, type, integration source, tags, and language

  • Get a specific testimonial by ID

  • Create new testimonials with full support for customer details, ratings, tags, and media

Related MCP server: X(Twitter) V2 MCP Server

Prerequisites

  • Node.js 18+

  • A Senja account on the Starter or Pro plan

  • A Senja API key (available from the Automate section in your Senja dashboard)

Setup

  1. Clone this repository:

    git clone https://github.com/andrewconnell/senja-mcp.git
cd senja-mcp

  2. Install dependencies:

    npm install

  3. Build the project:

    npm run build

Configuration

Claude Desktop

Add the following to your Claude Desktop configuration file (claude_desktop_config.json):

{
  "mcpServers": {
    "senja": {
      "command": "node",
      "args": ["/path/to/senja-mcp/lib/index.js"],
      "env": {
        "SENJA_API_KEY": "your-senja-api-key"
      }
    }
  }
}

Claude Code

Add the following to your Claude Code MCP settings:

{
  "mcpServers": {
    "senja": {
      "command": "node",
      "args": ["/path/to/senja-mcp/lib/index.js"],
      "env": {
        "SENJA_API_KEY": "your-senja-api-key"
      }
    }
  }
}

Environment Variables

Variable

Required

Description

SENJA_API_KEY

Yes

Your Senja API key

Available Tools

list_testimonials

Retrieve testimonials with optional filtering and sorting.

Parameters:

  • sort — Sort by date or rating (default: date)

  • order — Sort direction: asc or desc (default: desc)

  • approved — Filter by approval status

  • rating — Filter by star rating (1-5)

  • type — Filter by type: text or video

  • integration — Filter by source (e.g., twitter, google, linkedin)

  • tags — Filter by tag names

  • lang — Filter by language (ISO 639 code)

  • limit — Number of results (1-1000, default: 100)

  • page — Page number for pagination

get_testimonial

Retrieve a specific testimonial by ID.

Parameters:

  • id — The testimonial ID (required)

create_testimonial

Create a new testimonial.

Parameters:

  • type — Testimonial type: text or video (required)

  • customer_name — Name of the customer (required)

  • title — Testimonial title/headline

  • text — Testimonial text content

  • rating — Star rating (1-5)

  • url — Source URL

  • date — Date in ISO 8601 format

  • approved — Whether the testimonial is approved

  • customer_email — Customer email

  • customer_avatar — Customer avatar URL

  • customer_company — Customer company name

  • customer_tagline — Customer tagline or job title

  • customer_website — Customer website URL

  • integration — Integration source identifier

  • tags — Tags to apply

  • video_url — Video URL (for video testimonials)

License

MIT

Available Tools

3 tools
create_testimonialCreate TestimonialB

Create a new testimonial in your Senja project.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoSource URL
dateNoDate in ISO 8601 format (e.g., 2024-01-15T00:00:00Z)
tagsNoTags to apply to the testimonial
textNoTestimonial text content
typeYesTestimonial type: text or video
titleNoTestimonial title/headline
ratingNoStar rating (1-5)
approvedNoWhether the testimonial is approved
video_urlNoVideo URL (for video testimonials)
integrationNoIntegration source identifier
customer_nameYesName of the customer
customer_emailNoCustomer email
customer_avatarNoCustomer avatar URL
customer_companyNoCustomer company name
customer_taglineNoCustomer tagline or job title
customer_websiteNoCustomer website URL

TDQS

B3.4/5.0
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 only says 'create a new testimonial,' which indicates a write operation, but gives no information about side effects, idempotency, permissions, required fields beyond the schema, or what happens on creation. For a mutation tool with no annotation coverage, this is a meaningful gap.

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 with no filler or repetition. It communicates the essential action and scope efficiently, which is appropriate for a tool whose parameter details are fully captured in the 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 16 parameters, no annotations, and no output schema, this one-sentence description is not enough to fully orient an agent. It provides project context but omits behavioral expectations, creation semantics, and any guidance on required versus optional inputs beyond what the schema lists.

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 16 parameters with meaningful descriptions. The tool description adds no additional parameter context, which matches the baseline of 3 when the schema carries the semantic weight.

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 states a clear verb ('create') and resource ('testimonial'), and names the Senja project context. It is distinct from the sibling tools list_testimonials and get_testimonial, so an agent can tell create from read/list operations without opening the schema.

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

Usage Guidelines4/5

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

The operation type (create) clearly implies this should be used when adding a new testimonial, while list_testimonials and get_testimonial are for reading. However, it lacks explicit guidance about when not to use it or how to choose among alternatives in ambiguous cases.

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

get_testimonialGet TestimonialA

Retrieve a specific testimonial by its ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe testimonial ID

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It communicates a non-mutating read operation but does not disclose error behavior, return format, or authorization requirements. It is minimally transparent but not misleading.

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 succinct sentence that immediately conveys the action, resource, and selection criterion with no wasted 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 one-parameter read operation with a clear schema and sibling context, the definition is adequate. It lacks an output schema or error-handling notes, but the simplicity of the tool keeps this a minor gap.

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 covers 100% of the parameter and already describes 'id' as 'The testimonial ID'. The description merely repeats 'by its ID' without adding format, example, or distinction from other identifier parameters, so it adds little beyond schema.

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 (retrieve) and resource (testimonial) scoped by ID, clearly distinguishing it from list_testimonials (which retrieves many) and create_testimonials (which creates).

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 clearly implies using this tool when you have a specific testimonial ID and need that one record. It does not explicitly mention alternatives, but the sibling names and the 'by its ID' phrase provide sufficient context.

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

list_testimonialsList TestimonialsB

Retrieve testimonials from your Senja project with optional filtering and sorting.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoFilter by language (ISO 639 code)
pageNoPage number
sortNoSort by date or rating (default: date)
tagsNoFilter by tag names
typeNoFilter by testimonial type
limitNoNumber of results to return (1-1000, default: 100)
orderNoSort direction (default: desc)
ratingNoFilter by star rating (1-5)
approvedNoFilter by approval status
integrationNoFilter by integration source (e.g., twitter, google, linkedin)

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavior disclosure. It does state the operation is a retrieval (read-only) and explicitly mentions supported behaviors (optional filtering and sorting), which is useful. However, it lacks context about response shape, pagination behavior, defaults, or any access-related caveats, leaving notable gaps.

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 wasted words. The core action and resource are front-loaded, and the key extensibility (filtering/sorting) is included without unnecessary elaboration.

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 a 10-parameter tool with no output schema and no annotations, the description is too minimal. It does not describe what the return value looks like, mention defaults, or provide any usage context beyond the basic operation. For an agent to call this tool correctly, it would need more guidance on expected output or additional behavioral constraints.

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 fully documents all 10 parameters. The description does not add any parameter-level details beyond what is in the schema. The generic phrase 'optional filtering and sorting' adds no semantic value over the structured parameter definitions, so baseline 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 specifies a clear verb ('Retrieve'), a concrete resource ('testimonials from your Senja project'), and mentions the key behaviors of filtering and sorting. It naturally distinguishes itself from siblings: get_testimonial (single item) and create_testimonial (write operation) through the plural resource and read-oriented verb.

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 the siblings. The description does not mention that get_testimonial should be used for a single testimonial or create_testimonial for adding one. The intended usage is implied by the name and description, but no explicit when/when-not guidance is provided.

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.

  1. 3 tool updatesv1.0.1
    • First observedcreate_testimonial
    • First observedget_testimonial
    • First observedlist_testimonials
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: listing all testimonials, fetching a single testimonial by ID, and creating a new one. There is no overlap or ambiguity between these three actions.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern: list_testimonials, get_testimonial, create_testimonial. The naming is predictable and uniform.

Tool Count5/5

With three tools covering the core actions for the testimonial domain, the count is well-scoped and appropriate for a simple resource-focused server.

Completeness3/5

The tool set covers list, get, and create, but lacks update and delete operations that would normally be expected for a complete testimonial lifecycle. This is a notable gap, though agents can still read and add testimonials.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Reddit MCP Server

    Arindam200
    A
    license
    A
    quality
    F
    maintenance
    An MCP server that enables AI assistants to access and interact with Reddit content through features like user analysis, post retrieval, subreddit statistics, and authenticated posting capabilities.
    15
    301
    MIT

  • X(Twitter) V2 MCP Server

    NexusX-MCP
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server for interacting with the Twitter/X API v2, enabling AI assistants to retrieve tweets, post content, reply, quote, and more programmatically.
    1,020 npm
    13
    MIT

  • Jilebi

    Datron
    A
    license
    Not graded
    quality
    B
    maintenance
    A plugin-based MCP server that enables AI assistants to interact with external systems through custom tools, resources, and prompts.
    4
    AGPL 3.0