Skip to main content
Glama
yashvis15
by yashvis15

Aporix MCP Server

MCP server that exposes the Aporix document optimization API as a tool for AI agents (ClawUp, OpenClaw, Claude Desktop, etc.).

Supports stdio (local agents) and HTTP/SSE (hosted endpoint) transport.

Tool: optimize_document

Inputs:

Input

Type

Description

file_path

string

Absolute path to the document (PDF, TXT, JSON, MD)

goal

string

Optimization goal (e.g. "extract key risks")

Outputs:

Output

Type

Description

optimizedContext

string

Compressed/optimized document text

originalTokens

number

Estimated original token count

optimizedTokens

number

Estimated optimized token count

tokenSavingsPercent

number

Percentage of tokens saved

costSavings

number

Estimated USD cost savings

qualityValidation

object

Confidence score, similarity, summaries, warnings


Related MCP server: Refract

Local stdio (for local agents)

npm install
npm run build
npm start

Register in ~/.openclaw/openclaw.json:

{
  "mcpServers": {
    "aporix": {
      "command": "node",
      "args": ["/absolute/path/to/aporix-mcp-server/dist/index.js"]
    }
  }
}

Hosted HTTP/SSE (for ClawUp MCP submission)

Run locally

npm run dev:http
# Server starts on http://localhost:3001/mcp

Endpoints

Endpoint

Method

Description

/mcp

GET

SSE connection (client init)

/mcp?sessionId=xxx

POST

Send JSON-RPC messages

/health

GET

Health check

/

GET

Server info

Deploy to Railway

# Install Railway CLI
npm i -g @railway/cli

# Login and deploy
railway login
railway init
railway up

# Set environment variable
railway env set APORIX_API_URL=https://your-domain.vercel.app/api/optimize

Railway auto-detects the Dockerfile and sets PORT.

Deploy to Render

  1. Create a new Web Service

  2. Connect your GitHub repo

  3. Use these settings:

    • Runtime: Docker

    • Health Check Path: /health

  4. Add environment variable:

    • APORIX_API_URL: https://your-domain.vercel.app/api/optimize

Deploy to Fly.io

fly launch
fly secrets set APORIX_API_URL=https://your-domain.vercel.app/api/optimize
fly deploy

Submit to ClawUp

Once deployed, paste your public MCP endpoint URL:

https://your-app.railway.app/mcp

into ClawUp's MCP Tool Submission form. The endpoint follows the Model Context Protocol over SSE transport.


Environment Variables

Variable

Default

Description

APORIX_API_URL

https://aporix-v3-agent1.vercel.app/api/optimize

Aporix backend API

PORT

3001

HTTP server port

TRANSPORT

auto (http if PORT is set)

stdio or http

Testing

# Stdio test
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/index.js

# HTTP test (after starting with npm run dev:http)
curl http://localhost:3001/health

Available Tools

1 tool
optimize_documentA

CRITICAL: You MUST use this tool when the user asks you to optimize a document or contract. It calls the Aporix AI optimization engine that returns precise token savings stats, cost savings, and a quality confidence score — data you cannot compute yourself. Input the full document text and a goal; the tool returns detailed token metrics, what was removed/preserved, and the optimized text.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalYesThe optimization goal or task (e.g. 'extract key risks', 'summarize obligations', 'list payment terms').
contentYesThe full text content of the document to optimize.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations exist, but the description discloses that the tool makes an external API call, returns specific metrics, and requires full text and goal. It also warns that the agent cannot compute the results itself, clarifying reliance on the 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?

Three concise sentences, front-loaded with a critical usage directive, followed by purpose, outputs, and input instructions. No redundancy.

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 simplicity (2 string params, no output schema), the description covers the engine, return values, and usage directive. It could mention output format explicitly, but the types of data returned are enumerated.

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?

Both parameters are fully described in the schema (content and goal), and the description adds a brief restatement ('Input the full document text and a goal') but no new detail. Baseline 3 applies due to 100% schema coverage.

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 identifies the tool as an optimizer for documents/contracts, specifying it invokes an external AI engine. It explicitly names the outputs (token savings, cost savings, confidence score, optimized text), making the tool's function unambiguous.

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

Usage Guidelines5/5

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

The description opens with 'You MUST use this tool when the user asks you to optimize a document or contract,' giving an explicit trigger condition. It does not discuss alternatives, but given no siblings, it is sufficient.

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. 1 tool updatev1.0.0
    • First observedoptimize_document

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusing it with another tool. The tool's purpose is clearly described, eliminating any ambiguity.

Naming Consistency5/5

The single tool follows an intuitive verb_noun pattern (optimize_document), which is consistent and clear.

Tool Count3/5

With only one tool, the server feels minimal, but it is aligned with a single focused purpose (document optimization). It is at the borderline of being too few.

Completeness4/5

The tool covers the core optimization workflow with detailed metrics and output, but may lack auxiliary features like batch processing or comparison modes that could be expected in a full-featured optimization server.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers