Skip to main content
Glama
ksturgeon-td

tdrest

by ksturgeon-td
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

tdrest-mcp

A lightweight MCP (Model Context Protocol) server for making REST API calls to Teradata cloud services including:

  • Elastic Compute — Manage compute engine clusters and configurations

  • Enterprise Vector Store — Semantic search, RAG, and document ingestion

  • OMS — Database management and object operations

  • QueryGrid — Multi-system fabric connectivity

Supports custom authentication (Bearer JWT, Basic), Socks5 proxy routing, multipart file uploads, and progressive endpoint documentation.

Features

  • Universal REST Client — Execute any HTTP method with custom headers, auth, and request bodies

  • Bearer & Basic Auth — JWT tokens, username/password, custom headers with session persistence

  • Socks5 Proxy — Route through corporate proxies with optional auth

  • Multipart Uploads — Upload files combined with form fields (CSV, JSON, PDF, etc.)

  • Semantic Search — Search Vector Store collections with natural language queries

  • RAG Pattern — Retrieve documents + generate AI responses in one call

  • Progressive Help — Searchable endpoint documentation with examples and parameters

  • 50+ Endpoints — Auto-generated from Swagger specs (Elastic Compute, Vector Store, OMS, QueryGrid, etc.)

  • Swagger Auto-Parser — Endpoints loaded at startup; no hand-curation needed

  • Usage Guides — Best practices, workflows, and examples via searchable markdown guides

  • Hot-loadable APIs — Drop a Swagger spec in specs/ → restart → instant access

  • Dynamic Service URLs — Define any service via *_BASE_URL environment variables

  • Stateless Design — All compute logic lives in the cloud APIs; MCP just brokers requests

Related MCP server: MCP REST Server

Quick Start

Prerequisites

  • Node.js 18+ with npm

Installation

git clone <repo-url>
cd tdrest-mcp
npm install
npm run build

Configuration

Copy .env.example to .env and set your API base URLs:

cp .env.example .env
# Edit .env with your values

Run the MCP Server

npm start

The server listens on stdin/stdout and is ready to accept tool calls from Claude.

Connect to Claude Desktop

Edit ~/.claude/config.json (or equivalent) to include:

{
  "mcp-servers": {
    "tdrest": {
      "command": "node",
      "args": ["/path/to/tdrest-mcp/dist/index.js"],
      "env": {
        "ELASTIC_COMPUTE_BASE_URL": "https://preprod.globalcompute.qateradatacloud.com"
      }
    }
  }
}

Restart Claude Desktop, and the tools will appear in the tool menu.

Usage

Authentication

Option 1: Environment Variable (Recommended for long-lived tokens)

Set auth once in .env — no context overhead for subsequent calls:

DEFAULT_AUTH_TYPE=bearer
DEFAULT_AUTH_TOKEN=eyJhbGc...

All requests automatically use it. Agent calls can still override per-request.

Option 2: Session Auth (for interactive use)

User: "Authenticate with my Teradata JWT token"
Claude executes: set_auth {
  type: "bearer",
  token: "eyJhbGc..."
}

Auth is stored for the session and applied to all subsequent requests.

Make a REST Call

User: "List all clusters"
Claude executes: execute_rest_call {
  url: "https://preprod.globalcompute.qateradatacloud.com/clusters",
  method: "GET",
  // auth is applied automatically from session
}

Get Help on Endpoints

User: "What endpoints are available for clusters?"
Claude executes: get_syntax_help {
  query: "clusters"
}
Response:
  Found 2 endpoints matching "clusters":
  - GET /clusters — List all compute engine clusters for a site
  - POST /clusters — Create a new compute engine cluster
  ...

Get Usage Guides

User: "How do I set up a cluster?"
Claude executes: get_usage_guide {
  query: "cluster"
}
Response:
  Creating and Managing Clusters guide showing:
  - Step-by-step workflow
  - Config vs cluster distinction
  - Lifecycle management
  - Common errors and fixes

Upload a File

User: "Upload a document to the vector store"
Claude executes: execute_rest_call {
  url: "https://api.vectorstore.qateradatacloud.com/documents",
  method: "POST",
  files: {
    "document": { path: "/tmp/document.pdf" }
  },
  formData: {
    "collection_id": "my-collection"
  }
}

Project Structure

src/
├── index.ts              # MCP server + tool handlers
├── rest-client.ts        # HTTP client (axios + auth + proxy)
├── syntax-help.ts        # Endpoint registry and search
├── usage-guide.ts        # Usage guide registry
├── guide-loader.ts       # Auto-load guides from guides/ directory
├── swagger-parser.ts     # Swagger spec parser (auto-generates endpoints)
├── file-utils.ts         # File discovery and glob expansion
├── types.ts              # TypeScript interfaces
└── config.ts             # Environment config

specs/
├── global-compute-api.json        # Global Compute API (37 endpoints)
├── global-consumption-api.json    # Global Consumption API (3 endpoints)
└── vector-store-api.json          # Vector Store API (13 endpoints)

guides/
├── getting-started.md       # Quick introduction and basic workflows
├── clusters-setup.md        # Step-by-step cluster provisioning
└── error-handling.md        # Error codes and troubleshooting

tests/
└── ...                  # Unit tests

CLAUDE.md              # Detailed developer guide

Development

# Watch for TypeScript changes
npm run dev

# Run tests
npm test

# Run a single test
npm test -- src/path/to/test.spec.ts

# Lint
npm run lint
npm run lint:fix

Authentication & Security

  • Bearer Tokens: Tokens are stored in memory for the session and not persisted to disk.

  • Basic Auth: Username/password stored in memory; not logged.

  • Custom Headers: Any header can be set per-request or per-session.

  • HTTPS Only: All connections are HTTPS by default; HTTP is not enforced but discouraged.

Important: Do not commit credentials to the repository. Use environment variables or .env files (which are in .gitignore).

Proxy Support

User: "Route through a Socks5 proxy at proxy.corp.com:1080"
Claude executes: set_proxy {
  type: "socks5",
  host: "proxy.corp.com",
  port: 1080,
  username: "user",      // optional
  password: "pass"       // optional
}

All subsequent requests route through the proxy until set_proxy { type: "none" } is called.

Adding New API Specs

The server auto-loads endpoints from Swagger/OpenAPI specs. To add a new API:

  1. Place the Swagger spec in specs/my-api.json

  2. Restart the server — endpoints load automatically at startup

  3. Search with get_syntax_help — all endpoints are immediately searchable

No code changes needed! Example:

# Copy your Swagger spec
cp /path/to/new-api-swagger.json specs/new-api.json

# Restart the server
npm start

# Now Claude can search and use all endpoints from new-api.json

The parser extracts:

  • Endpoint path and HTTP method

  • Parameter names, types, and requirements

  • Request body schema properties

  • Operation summary and description

  • Response descriptions and examples

  • Tags for better discoverability

Adding Usage Guides

Create markdown guides in guides/ to document best practices and workflows:

  1. Create a new file — guides/my-guide.md

  2. Add YAML frontmatter (optional):

    ---
title: My Guide Title
description: One-line description
tags: [tag1, tag2]
---

  3. Write markdown content — Guidelines, workflows, examples

  4. Restart the server — Guides auto-load at startup

  5. Search with get_usage_guide — Guides are immediately discoverable

No code changes needed! Users can then search by:

  • Guide name: get_usage_guide("my-guide")

  • Keyword: get_usage_guide("cluster")

  • List all: get_usage_guide("list")

Limitations

  • No auto token refresh — If a JWT expires, call set_auth again with a fresh token

  • No request templating (yet) — Request bodies are literal; Handlebars templating planned

  • No response filtering (yet) — Full responses returned; jq-like queries planned

  • Blocking uploads — Large files block the connection; chunking coming in Phase 2

Documentation

Supported APIs

Service

Status

Endpoints

Auth

Global Compute

✅ Complete

37 (clusters, configs, OMS, QueryGrid, site-settings)

Bearer, Basic

Vector Store

✅ Complete

13 (collections, search, ingest, permissions, health)

Bearer, Basic

Any REST API

✅ Supported

Unlimited (universal client)

Bearer, Basic, Custom

Contributing

See CLAUDE.md for architectural details, testing patterns, and guidelines for adding endpoints.

License

MIT

Support

  • Bug reports — GitHub Issues

  • Feature requests — GitHub Discussions

  • Architecture questions — See CLAUDE.md Q&A section

  • Deployment help — See DEPLOYMENT.md troubleshooting

Available Tools

8 tools
execute_rest_callA

Execute a REST API call with support for custom auth, Socks5 proxy, and multipart uploads. Use get_service_config to see available base URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull URL to the REST endpoint
authNoAuthentication config. Omit to use session auth if set. Example: {"type": "bearer", "token": "..."} or {"type": "basic", "username": "...", "password": "..."}
bodyNoRequest body (JSON object or string)
filesNoFiles to upload (multipart). Key is field name, value is {"path": "/path/to/file"}
proxyNoProxy config. Example: {"type": "socks5", "host": "localhost", "port": 1080}
methodYesHTTP method
headersNoCustom HTTP headers (e.g., {"X-API-Key": "value"})
timeoutNoRequest timeout in milliseconds (default: 30000)
formDataNoForm fields as key-value pairs (string, number, or boolean values)
filePatternNoGlob pattern to match files (e.g., /tmp/*.pdf, ~/docs/**/*.csv). Alternative to explicit files.
validateStatusNoIf true, non-2xx responses throw error. If false (default), all responses succeed.

TDQS

A3.6/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 full burden. It discloses high-level features (custom auth, proxy, multipart) but does not detail side effects, limitations, error handling, or performance behaviors beyond what is in the schema.

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 long, front-loads the core purpose, and contains no extraneous information. Every sentence earns its place.

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?

Despite the tool's complexity (11 parameters, no output schema), the description is very brief. It omits critical context such as response format, dependency on setup tools (set_auth, set_proxy), and typical use cases. Missing information that would help an agent use the tool correctly.

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 baseline is 3. The description adds a hint about using get_service_config for base URLs, which relates to the url parameter, but does not add significant meaning beyond the schema's parameter descriptions.

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 'Execute' and resource 'REST API call', and distinguishes from siblings by listing unique features like custom auth, proxy, and multipart uploads. It also directs to get_service_config for base URLs, which differentiates its use.

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 mentions use of get_service_config to see base URLs, implying a prerequisite, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or context for sibling tools are provided.

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

find_filesA

Find files matching a glob pattern (e.g., /tmp/.pdf, ~/Documents/**/.csv)

ParametersJSON Schema
NameRequiredDescriptionDefault
patternYesGlob pattern to search for files (e.g., /tmp/*.pdf, ~/data/**/*.csv)

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 full burden. It explains the glob pattern usage but does not disclose performance implications, behavior on invalid patterns, or whether it searches recursively by default.

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 clear examples, no unnecessary words. Highly concise and front-loaded.

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 one parameter and no output schema or annotations, the description covers the core function well. Minor gaps exist: no mention of error handling or behavior with no matches.

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% as the pattern parameter is described in the schema. The tool description essentially repeats the same information without adding new semantics.

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 tool finds files using a glob pattern, with examples. It distinguishes from sibling tools like list_files by specifying pattern matching.

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 indicates when to use (for glob pattern search) but doesn't explicitly exclude cases or mention alternatives. Implicitly contrasts with list_files.

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

get_service_configA

Get configured service base URLs (Elastic Compute, Vector Store, timeouts, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

Without annotations, the description indicates a read operation ('Get'), but does not disclose any behavioral traits such as authentication requirements, error conditions, or side effects. It adds minimal context beyond the verb.

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 wasted words. Every part contributes meaning.

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 parameterless retrieval tool, the description explains what is returned (base URLs for specific services). However, it lacks details on response format, which could aid an agent. No output schema exists to supplement.

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 tool has zero parameters, and schema description coverage is 100% trivially. The description adds no parameter details, as none exist, so the baseline score of 4 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 clearly states the tool retrieves configured service base URLs, listing specific examples (Elastic Compute, Vector Store, timeouts). This distinguishes it from siblings like execute_rest_call, which executes requests rather than retrieving configuration.

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 use when needing base URLs for configured services, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites.

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

get_syntax_helpB

Get help and syntax for available API endpoints from Swagger specs

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query (endpoint name, method, or keyword). Use "list" to see all endpoints.

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as whether it fetches live specs, caches results, or any rate limits. The mention of Swagger specs is vague about the retrieval method.

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?

Single sentence, zero wasted words. Efficient and to the point.

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

Completeness3/5

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

Minimal but adequate for a simple tool with one parameter and no output schema. Could describe output format or scope of help provided.

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 coverage is 100%, so baseline is 3. The description does not add information beyond the schema's property description, which already includes the hint about using 'list'.

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 the tool provides help and syntax for API endpoints from Swagger specs. It distinguishes from siblings like execute_rest_call which executes calls, and get_usage_guide which provides general usage.

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 on when to use this tool versus alternatives like get_usage_guide. The description implies use when needing syntax help but does not specify exclusions or context.

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

get_usage_guideA

Get usage guides with best practices, workflows, and examples for APIs

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query or guide name. Use "list" to see all guides, or search by keyword (e.g., "clusters", "error handling").

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description should disclose safety and side effects. It describes the content returned but does not explicitly state read-only behavior, rate limits, or response structure.

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 a single concise sentence that front-loads the main action. It is efficient but could be slightly more structured to separate purpose from usage notes.

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 (one required parameter, no output schema, no annotations), the description covers the essential purpose and usage. It lacks details on return format but is adequate for selection.

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 coverage is 100% and the parameter description already explains how to use the query field (e.g., 'list' for all guides, keyword search). The tool description adds no additional semantic value beyond the 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 retrieves usage guides with best practices, workflows, and examples. However, it does not differentiate from the similar sibling 'get_syntax_help', which could cause 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?

The description implies usage for obtaining guides on specific topics via the query parameter, but does not explicitly state when to use this tool versus alternatives like 'get_syntax_help'.

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

list_filesB

List files in a directory with optional filtering by extension

ParametersJSON Schema
NameRequiredDescriptionDefault
directoryYesDirectory path (e.g., /tmp, ~/Documents). Use ~ for home directory.
extensionNoOptional file extension filter (e.g., ".pdf", ".csv"). Comma-separated for multiple.
recursiveNoWhether to include subdirectories in listing (default: false)

TDQS

B3.4/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It notes optional filtering and recursion but omits behavioral traits like whether it follows symlinks, handles permissions, performance for large directories, or what happens with non-existent directories.

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?

Single sentence that front-loads the core purpose. Every word is necessary with no fluff.

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?

While simple, the description lacks essential details like output format (list of filenames? full paths?), error handling, and behavior with edge cases (e.g., empty directory, permission denied). For a file listing tool, more completeness is expected.

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 baseline is 3. The description adds minimal extra meaning beyond restating the extension filter and directory path examples already in 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?

The description uses a specific verb ('List') and resource ('files') with clear scope ('in a directory') and optional filtering. It effectively distinguishes from sibling tools like 'find_files' and 'execute_rest_call'.

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 vs alternatives. The description implies usage for directory listing but doesn't mention when not to use or reference sibling tools like 'find_files' for search functionality.

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

set_authB

Set session-level authentication for subsequent requests

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesAuthentication type
tokenNoBearer token (for bearer auth)
passwordNoPassword (for basic auth)
usernameNoUsername (for basic auth)
headerNameNoCustom header name (for custom auth)
headerValueNoCustom header value (for custom auth)

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It mentions 'session-level' but does not explain side effects (e.g., whether calls overwrite previous settings, if it resets, or how it interacts with execute_rest_call). This lack of detail limits 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?

The description is a single, front-loaded sentence that effectively communicates the core purpose. It contains no redundant words and earns its place by being concise and useful.

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?

Despite having 6 parameters (one required) and no output schema, the description fails to explain parameter interactions, expected outcomes, or error scenarios. For a state-modifying tool, this is insufficiently complete, especially without annotations.

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 parameters are well-documented within the schema. The description adds no additional meaning or usage hints beyond the schema, resulting in a 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 clearly specifies the verb 'set', the resource 'auth', and the scope 'session-level', effectively distinguishing it from sibling tools like execute_rest_call or find_files. It leaves no ambiguity about what the tool does.

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 is provided. However, given the unique functionality (setting authentication) and the context of sibling tools, usage is implicitly clear. A score of 3 reflects the absence of explicit when/when-not instructions.

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

set_proxyB

Set session-level proxy for subsequent requests

ParametersJSON Schema
NameRequiredDescriptionDefault
hostNoProxy host
portNoProxy port
typeYesProxy type
passwordNoProxy password (optional)
usernameNoProxy username (optional)

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It only mentions 'session-level' persistence, but fails to disclose behavioral traits like what happens when type='none', whether previous proxy settings are overridden, required permissions, or error conditions.

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 but lacks structure. It is front-loaded but too minimal to provide useful context; every word earns its place but there is no additional information.

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 5 parameters and no output schema or annotations, the description is insufficient. It does not explain return values, error handling, or how to verify proxy setting effectiveness. The brevity leaves significant gaps.

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 coverage is 100% with all parameters described. The description adds minimal meaning beyond the schema ('session-level proxy'). Baseline 3 is appropriate as the schema already does the heavy lifting.

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 'Set' and the resource 'session-level proxy' with scope 'for subsequent requests'. It differentiates well from sibling tools like set_auth (authentication) and execute_rest_call (making HTTP requests).

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 (e.g., set_auth). The description does not mention prerequisites, ordering, or contexts where this should be used or avoided.

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. 8 tool updatesv0.1.0
    • First observedexecute_rest_call
    • First observedfind_files
    • First observedget_service_config
    • First observedget_syntax_help
    • First observedget_usage_guide
    • First observedlist_files
    • First observedset_auth
    • First observedset_proxy
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.7/5.0

Scored across 8 tools

Disambiguation4/5

Tools are mostly distinct: REST execution, configuration, help, and file operations. Some overlap between find_files and list_files, and between get_syntax_help and get_usage_guide, but descriptions help differentiate.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, e.g., execute_rest_call, find_files, get_service_config.

Tool Count5/5

8 tools is well-scoped for a REST client utility, covering setup, execution, help, and file discovery without being excessive.

Completeness4/5

Covers key aspects of REST API interaction: auth, proxy, execution, config, and help. Missing maybe a tool to clear credentials or inspect raw responses, but core workflow is supported.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP REST Server

    gyuco
    F
    license
    A
    quality
    D
    maintenance
    Enables interaction with any REST API through token or login authentication, with automatic Swagger/OpenAPI documentation integration for endpoint discovery and comprehensive HTTP request support.
    7
    -

  • Tableau MCP Server

    LokiMCPUniverse
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables reading and writing to Tableau Server or Tableau Cloud via the REST API, supporting operations on sites, projects, workbooks, views, and data sources.
    4
    -

  • logicmonitor-mcp

    MSPbotsAI
    A
    license
    Not graded
    quality
    C
    maintenance
    Exposes the LogicMonitor REST API as MCP tools with per-request LMv1 authentication, enabling querying of devices, alerts, reports, and more.
    Apache 2.0