Skip to main content
Glama
adi0ri

gateway_lab.mcp_server

by adi0ri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

FDE Assessment

Python implementations of four tasks covering MCP servers, security gateways, streaming guardrails, and model routing.

Tasks

Task

Implementation

1. MCP server

Official SDK stdio server with strict input validation and JSON-RPC errors

2. MCP gateway

JWT authentication and tool authorization for admin_* calls

3. Streaming guardrail

Bounded PII redaction for emails, SSNs, and card numbers across chunks

4. Model router

SQLite token limiter and fallback routing: 50,000 tokens/minute/key, 3-second primary timeout

Related MCP server: Easy MCP Server

Setup

Requires Python 3.11+.

python -m venv .venv

Activate with source .venv/bin/activate (macOS/Linux) or .\.venv\Scripts\Activate.ps1 (Windows PowerShell), then run:

python -m pip install -r requirements.lock
python -m pip install -e . --no-deps
python -m gateway_lab.demo

The gateway runs at http://127.0.0.1:9000, with mock upstreams on port 9001. Demo credentials are printed in the terminal. No paid API keys are needed; refunds are simulated.

From another activated terminal, run python scripts/exercise_gateway.py to check authorization, streaming redaction, and fallback. Use python -m gateway_lab.mcp_server for the standalone stdio server.

Tests

python -m pytest -q
python -m ruff check .
python -m ruff format --check .
python -m pip check

65 tests cover protocol handling, authorization, stream boundaries, SQLite concurrency, and fallback. CI runs on Windows and Linux with Python 3.11 and 3.13.

See design notes, verification results, and configuration for details.

Available Tools

2 tools
get_customer_recordC

Fetch a mock customer record

ParametersJSON Schema
NameRequiredDescriptionDefault
customer_idYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'mock' and 'fetch', implying a read-only operation, but does not state side effects, error behavior, return format, or whether the record is guaranteed to exist. The description adds minimal behavioral context.

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, concise sentence with no redundant information. It front-loads the core action and resource, making it efficient to parse.

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 tool's simplicity and lack of output schema, the description is too sparse. It does not explain what a 'mock customer record' contains, how errors are handled, or what the agent should do with the result. An agent calling this tool would have to infer these details from elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention the 'customer_id' parameter at all, and schema description coverage is 0%. Since the description is the only source of parameter context, its silence leaves the parameter meaning entirely to the schema's pattern and constraints, which is insufficient for an agent to know how to construct a valid request beyond the literal pattern.

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 clear verb 'Fetch' and a specific resource 'mock customer record', which distinguishes it from the sibling 'trigger_refund'. It is unambiguous 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 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 sibling tool is named but not referenced in the description, leaving the agent to infer usage context without any explicit cues.

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

trigger_refundB

Simulate a refund; no real money moves

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYes
reasonYes
customer_idYes

TDQS

B3.2/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 behavioral disclosure. It does state the most important behavioral fact: 'no real money moves'. However, it does not explain whether a simulated refund record is persisted, whether a refund ID or result is returned, or what side effects may occur beyond the monetary aspect.

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 very concise and front-loaded, immediately stating that this is a simulation and emphasizing the no-money-moves guarantee. It contains no filler words. It could be slightly expanded with usage or side-effect detail, but as written it is clear and easy to scan.

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 three required parameters, no annotations, no output schema, and only one sibling tool, the description is too thin. It does not explain what the simulation returns, whether it validates a real customer, or how it integrates with get_customer_record. An agent would need to guess at the operational contract.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no detail about customer_id, amount, or reason. The parameter names are somewhat self-explanatory eb purpose, but the description does not clarify units, expected source of the values, or how each parameter affects the simulation.

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 and resource: 'Simulate a refund'. It also clarifies the key distinction from a real refund with 'no real money moves'. This clearly separates it from the sibling tool get_customer_record, which is a retrieval operation.

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 explicit when-to-use or when-not-to-use guidance is provided. The description implies a testing or simulation context but does not mention alternatives or conditions that would make this tool preferable. The sibling tool is not referenced at all.

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 updatesv1.0.0
    • First observedget_customer_record
    • First observedtrigger_refund
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 perform clearly separate operations: retrieving a customer record versus triggering a refund. There is no functional overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the same snake_case verb_noun pattern (get_customer_record, trigger_refund). The naming is concise, predictable, and consistent.

Tool Count3/5

Two tools is at the low end of what feels useful; for a mock lab it may be intentional, but the surface is thin. Each tool earns its place, but there is little room for broader workflows.

Completeness2/5

The server covers a single lookup and a single action, with no way to list customers, check refund status, or cancel/reverse a refund. Agents would hit dead ends for any multi-step workflow beyond a simple demo.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Easy MCP Server

    joshwyatt
    A
    license
    Not graded
    quality
    D
    maintenance
    A simple toolkit for creating MCP servers with stdio and SSE transport, auto-validating tools via Pydantic.
    MIT

  • veriloop

    arvindcr4
    A
    license
    A
    quality
    C
    maintenance
    Exposes a verified tool registry (calculator, sandboxed file read, web fetch) over MCP stdio, enabling any MCP-capable client to reuse the same tools from the inspectable ReAct loop.
    3
    MIT

  • Schema Sentinel

    SanjoyDat1
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server that validates tool calls against JSON Schema, performs deterministic repair, redacts secrets, and maintains a hash-chained audit ledger.
    -