Skip to main content
Glama
mayank2012

Actionstep MCP Server

by mayank2012
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Actionstep MCP Server

This project is a starter TypeScript implementation of an MCP server for Actionstep-style conveyancing automation. It exposes a small set of example tools and includes a simple HTTP health endpoint for local testing.

Project overview

The current implementation provides:

  • A basic Express HTTP server

  • A health check endpoint at /health

  • An MCP server with two example tools:

    • ping

    • list_conveyancing_actions

Related MCP server: mcp-base

Tech stack

  • TypeScript

  • Node.js

  • Express

  • Model Context Protocol SDK

  • Zod

  • dotenv

Folder structure

  • src/ – application source code

  • dist/ – compiled JavaScript output

  • package.json – scripts and dependencies

  • tsconfig.json – TypeScript compiler configuration

Installation

From the project root, install dependencies:

npm install

Build

Compile the TypeScript source:

npm run build

Run

Start the server:

npm start

Or run the build and start flow directly:

npm run dev

Health check

Once running, the server responds at:

http://localhost:3000/health

Next steps

This starter project is intended as a foundation for a production-ready Actionstep MCP server. Suggested next steps include:

  • Connecting the tools to the real Actionstep API

  • Adding OAuth 2.0 authentication and token refresh

  • Expanding the tool registry for matters, documents, tasks, and settlement workflows

  • Adding secure secret storage and audit logging

Node.js_MCP_Server_Development

Available Tools

2 tools
list_conveyancing_actionsB

Lists starter conveyancing automation actions exposed by the MCP server.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are present, so the description must fully cover behavioral traits. It only indicates a list operation but omits details like idempotency, side effects, or authentication needs.

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, front-loaded with the action and resource. Every word is necessary and no extraneous content exists.

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 output schema and annotations, the description should explain what 'starter conveyancing automation actions' means and what the returned data looks like. It falls short of providing complete context for an 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?

With zero parameters and 100% schema coverage, the description adds the qualifier 'starter', suggesting a subset of actions rather than all conveyancing actions. This adds meaning beyond the empty schema.

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 that the tool 'lists starter conveyancing automation actions', specifying a verb and resource. However, it does not differentiate from the sibling tool 'ping', though the distinction is obvious.

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 only states what it does, with no context on prerequisites or exclusions.

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

pingA

Returns a simple readiness response from the Actionstep MCP server.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/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 full burden. It does not disclose whether the tool is read-only, idempotent, or if it has side effects. For a ping, it is likely safe, but the description lacks explicit 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?

A single, well-formed sentence that communicates the purpose without extraneous words. It is appropriately front-loaded with the core action 'Returns...'.

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 tool with no parameters and no output schema, the description adequately covers what the tool does. It could mention that it is a health check or that it returns a constant response, but it is sufficient for an agent to understand its 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?

The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds context by stating it returns a readiness response, which is sufficient.

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?

Clearly states it returns a readiness response, which is a specific and unambiguous purpose. The sibling tool list_conveyancing_actions is completely different, so no confusion.

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?

No explicit guidance on when to use this tool versus alternatives. However, the purpose as a health check is implied, and there is no scope for misuse given no parameters and no side effects. A simple 'when to use' statement would improve clarity.

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. 2 tool updatesv0.1.0
    • First observedlist_conveyancing_actions
    • First observedping
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

B3.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one lists conveyancing actions, the other is a health check. There is no overlap or confusion.

Naming Consistency3/5

'list_conveyancing_actions' follows a descriptive verb_noun pattern, but 'ping' uses a different single-verb style. While acceptable, the inconsistency prevents a higher score.

Tool Count2/5

With only 2 tools, the server feels extremely minimal for a system named 'Actionstep'. Most servers in this domain would require more tools to be useful.

Completeness2/5

Only a listing operation and a health check are provided. No creation, modification, deletion, or execution of actions, which are essential for a conveyancing tool.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Server Scaffold

    vjouenne76
    F
    license
    B
    quality
    D
    maintenance
    A basic starter project for building Model Context Protocol (MCP) servers that enables standardized interactions between AI systems and various data sources through secure, controlled tool implementations.
    2
    -

  • mcp-base

    sesopenko
    A
    license
    Not graded
    quality
    D
    maintenance
    A bare-bones FastMCP server template designed to serve as a starting point for building custom Model Context Protocol servers. It provides a foundational structure for implementing tools over HTTP and includes a built-in health check utility.
    GPL 3.0

  • connect-claude

    felixtosh
    F
    license
    Not graded
    quality
    D
    maintenance
    MCP server scaffold that exposes stubbed tools for listing, searching, and summarizing sources, with built-in OAuth 2.1 authorization flow for Claude integration.
    -

  • mcp-app

    echomodel
    F
    license
    Not graded
    quality
    D
    maintenance
    Framework for building and running MCP servers as HTTP services. Define tools as pure Python functions, wire up with two lines, run with one command.
    -