Provides OpenTelemetry tracing and metrics for MCP tool calls and HTTP requests, exporting spans to an OTLP endpoint.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Advanced MCP Platform search my workspace roots for files containing TODO"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python 3.11+ FastMCP service that retains the original tool names while adding signed tenant capabilities, per-user workspace roots, bounded tool input, audit-friendly JSON logs, metrics, OpenTelemetry spans, and authenticated Streamable HTTP.
Related MCP server: ForgeBridge
The Model Context Protocol (MCP) is an open standard for connecting AI applications (clients) to external capabilities and context (servers). A client can discover the server's available tools and call them through a consistent protocol, rather than using a different custom integration for every service. MCP also defines related capabilities such as resources, prompts, progress notifications, and client-controlled sampling.
In this project, the client initializes an MCP session, discovers tools such as list_root_files and search_in_roots, and sends structured tool requests. The server checks the caller's permissions, performs allowed work, then returns results and (where supported) progress/log notifications. For sampling, the server asks the client to generate text; the client remains responsible for whether and how it uses a model.
MCP is useful when you want reusable integrations with clear capability boundaries. It does not itself make a tool safe: the application still has to authenticate callers, validate inputs, enforce file access, and decide which capabilities to grant.
The dashboard's MCP explained section has a clickable process diagram; select a step to read its role in the request flow.
MCP client
├─ stdio (local trusted process) ──────────────────────────────┐
└─ Streamable HTTP + JWT → trace/auth middleware → FastMCP │
├─ tools ─────┤
├─ sandbox │
└─ sampling ←─┘The control flow is: verify bearer token and required MCP scope; bind stateful MCP sessions to the tenant/user that initialized them; resolve signed workspace grants; enforce a per-principal tool rate limit; validate input; execute within a traced tool span; return a normal MCP result/error. The HTTP health/readiness routes are public; the MCP endpoint is not. No protocol extensions are introduced.
mcp_advanced/
config.py Typed environment settings and startup validation
security.py JWT verifier, capability checks, rate limits, path sandbox
observability.py JSON logging, audit events, metrics, OTel HTTP/tool spans
server.py FastMCP tools, auth configuration, health/metrics endpoints
cli.py Operator token issuer
server.py Backward-compatible server entry point
client.py Feature demo and authenticated HTTP client
webapp.py Loopback-only interactive local demo dashboard
frontend/ Dashboard UI, event filtering, approval prompt, run history
tests/ Sandbox, auth, stdio, HTTP, and dashboard integration testspy -3.11 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[test,sampling]"
python -m pytestThe core sampling example uses a local stub; .[sampling] installs the optional Anthropic client for real sampling. Never put provider keys in the repository.
python client.py stdiostdio is intended for a local trusted parent process. The root is MCP_ROOT when set, otherwise the project directory. Do not expose a stdio process with an untrusted caller as its parent.
Set the same signing secret for the server and operator token issuer. Use a randomly generated value of at least 32 characters and keep it in a secret manager in deployed environments.
$env:MCP_JWT_SECRET = python -c "import secrets; print(secrets.token_urlsafe(48))"
$env:MCP_DATA_DIR = "$PWD\.mcp-data"
# Create the server-side workspace root. Files for this user belong beneath it.
New-Item -ItemType Directory -Force "$env:MCP_DATA_DIR\tenants\acme\alice\roots\src" | Out-Null
# Issue a short-lived, least-privilege token. Copy its output for the client.
$token = python -m mcp_advanced.cli issue-token `
--tenant acme --user alice --root src `
--scope mcp:tools --scope files:read --scope sampling:request
# Terminal 1
python server.py --transport http
# Terminal 2
$env:MCP_JWT_SECRET = "<same signing secret>"
$env:MCP_DATA_DIR = "$PWD\.mcp-data"
$env:MCP_ACCESS_TOKEN = "<issued token>"
python client.py http http://127.0.0.1:8000/mcpThe token's tenant_id, sub, scopes, audience, issuer, expiry, and relative roots are validated. Tenant roots live beneath MCP_DATA_DIR/tenants/<tenant>/<user>/roots; relative grants cannot contain traversal. Supported scopes are mcp:tools, files:read, and sampling:request. The admin CLI is the trusted token issuer; do not expose it as an unauthenticated endpoint.
Useful settings:
Variable | Default | Purpose |
| unset | Required for HTTP; at least 32 characters |
|
| Expected JWT issuer |
|
| Expected JWT audience |
|
| Short-lived token lifetime |
|
| Tenant-isolated workspace storage |
| project directory | Trusted local stdio root |
|
| Per-user process-local tool rate |
|
| Stateful session idle timeout |
|
| Maximum active stateful sessions |
|
| File read/search size bound |
|
| Search file-count bound |
|
| Use stateless Streamable HTTP |
|
| Disable SSE response streaming |
| unset | Enable OTLP trace export |
Configuration is parsed at startup and invalid security-sensitive values fail closed. HTTP startup without MCP_JWT_SECRET fails.
$env:MCP_JWT_SECRET = "<random secret, at least 32 characters>"
$env:MCP_STATELESS_HTTP = "true"
python server.py --transport httpStateless mode supports authenticated tools and signed per-user roots. As defined by Streamable HTTP/MCP behavior, it cannot preserve a client session for server-initiated sampling or a standing progress/log stream. The demo client skips those two exercises in stateless mode; summarize_text and review_file return a clear sampling_unavailable error if explicitly called. JSON-response mode likewise does not provide live notification delivery.
python webapp.py
# Visit http://127.0.0.1:8080The dashboard shows live tool/log/progress events, supports filtering, keeps recent run summaries in process memory, and pauses sampling for a human to approve/reject or edit the prompt. It binds only to a loopback IP because it has no authentication. It launches the local stdio demo, not the multi-tenant HTTP service; never expose it to a network or use it as a production tenant console.
$env:MCP_JWT_SECRET = python -c "import secrets; print(secrets.token_urlsafe(48))"
docker compose up --buildThe container runs as a non-root user, drops Linux capabilities, uses a read-only root filesystem, and keeps workspace data in a named volume. The compose port is loopback-bound by default. Configure an external OTLP collector by setting OTEL_EXPORTER_OTLP_ENDPOINT.
This repository includes a Render Blueprint at render.yaml for the authenticated MCP HTTP service. It provisions a web service, generates MCP_JWT_SECRET in Render, stores tenant workspaces on a persistent disk, and checks /ready.
Push or merge this repository to GitHub.
In Render, choose New → Blueprint, connect AHAAkash/Own_MCP_Server, and select the branch containing render.yaml.
Review the Blueprint resources and confirm creation. Render may require a paid Starter service for the persistent disk.
Wait for the service to become healthy. Its MCP endpoint is https://<your-render-service>.onrender.com/mcp; /health, /ready, and /metrics are also available.
In Render's environment settings, copy the generated MCP_JWT_SECRET into a trusted local terminal (do not commit it), then issue a short-lived token:
$env:MCP_JWT_SECRET = "<copy from Render environment settings>"
$env:MCP_JWT_ISSUER = "https://auth.local.invalid"
$env:MCP_JWT_AUDIENCE = "advanced-mcp"
$token = python -m mcp_advanced.cli issue-token `
--tenant acme --user alice --root src `
--scope mcp:tools --scope files:read --scope sampling:request
$env:MCP_ACCESS_TOKEN = $token
python client.py http https://<your-render-service>.onrender.com/mcpCreate or upload authorized workspace files beneath the persistent disk's /var/data/tenants/<tenant>/<user>/roots/<root> path using a trusted deployment workflow before requesting file tools. Do not make the disk publicly accessible.
Render deploys the MCP HTTP service only. The browser dashboard remains a loopback-only stdio demo and is intentionally not exposed by this Blueprint. Stateless mode is not enabled because the default demo uses MCP sampling and notifications. The service and disk incur Render charges according to your Render plan.
Authentication: HMAC-SHA256 JWTs with issuer, audience, expiry, user, tenant, scopes, and relative roots. There is no anonymous HTTP MCP access and no hard-coded development signing key.
Capabilities: each tool checks its required scope. A file token does not automatically grant sampling.
Session isolation: the stateful HTTP boundary binds the MCP session ID to the tenant/user that initialized it; session state itself is held in the FastMCP process.
Filesystem: traversal, out-of-root absolute paths, and symlinks are rejected; hidden virtual environments and VCS trees are excluded from listing/search. Reads and searches have size, result, and file-count bounds and execute off the event loop.
Isolation: HTTP workspace paths are separated by tenant and user; signed root grants are relative to that user's directory. The container uses a dedicated persistent volume. For mutually hostile tenants, use separate OS/container or volume boundaries as well; directory names alone are not a kernel security boundary.
Rate limits: token-bucket limits are per user, but currently process-local.
Auditing: authenticated tool calls, sampling requests/failures, and file read attempts emit structured JSON logs to stdout. Ship these logs to a protected centralized sink for durable retention.
Errors: input, capability, path, sampling, and rate-limit failures include stable prefixes such as invalid_input, insufficient_scope, path_forbidden, sampling_unavailable, and rate_limited.
Observability: tool and HTTP request spans, W3C trace-context extraction, sampling spans, tool latency, HTTP request counts, sampling success/failure, progress notification drops, and stateful HTTP session-duration metrics are available. Metrics are in process memory and exposed at /metrics; /health and /ready are unauthenticated liveness/readiness probes.
This is a security-oriented single-process foundation and demo, not a finished multi-replica hosted service. Specifically:
FastMCP's stateful session manager and the current rate limiter/metrics are in memory. Stateful HTTP must stay on one instance (or use deployment-level sticky routing); a Redis/Postgres session-store adapter and distributed rate limiter are not implemented.
Workspace directories share the configured volume at the OS level; hostile-tenant deployments need stronger container/volume isolation.
JSON audit output is not a durable audit database. Configure log collection, retention, redaction, alerting, and key rotation before production use.
Sampling has timeouts and explicit errors but no circuit breaker. The dashboard approval queue/run history are process-local and intentionally loopback-only.
MCP resources for files/prior results and persistent project/run-history APIs are not implemented.
OTLP traces export only when the endpoint is configured. Protect trace/log backends and avoid recording sensitive prompt/file contents there.
Do not treat a successful build or a local demo as evidence of compliance or production approval. Before internet-facing deployment, add an organizational identity/token issuer, secret rotation and revocation, shared distributed state/rate-limit storage, durable audit retention, per-tenant runtime isolation, resource quotas, and load/security testing.
python -m pytest
mypy mcp_advanced client.py webapp.py server.py testsThe suite covers token validation, capabilities, traversal/symlink rejection, tenant root separation, rate limiting, stdio operation from a different working directory, authenticated and unauthenticated stateful HTTP, stateless HTTP file tools, and dashboard sampling approval/history.
List non-symlink files under tenant-granted workspace roots.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | * | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that results exclude symlinks and are limited to tenant-granted roots, but it does not explain permissions, pagination, pattern matching behavior, or result handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It states the scope and key exclusion efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, but the two input parameters are entirely undocumented in both schema and description. For a tool with optional filtering and limiting parameters, this leaves important invocation details missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have 0% schema description coverage, and the description does not mention pattern or max_results at all. An agent cannot infer how pattern filtering or result limiting behaves from this definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: listing non-symlink files under tenant-granted workspace roots. It clearly scopes the operation, but it does not explicitly distinguish this listing behavior from sibling tools such as search_in_roots or read_root_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states what the tool does but gives no guidance on when to use it instead of alternatives like search_in_roots or read_root_file. There are also no exclusions or conditions indicating when listing would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate bounded work and stream log + progress notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| delay | No | ||
| steps | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose that work is bounded and that logs and progress notifications are streamed. However, it omits important behavioral traits such as whether the call blocks, whether work can be cancelled, how delay/steps affect runtime, or what the streaming notifications contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded with the core action and contains no filler. Every phrase ('simulate bounded work', 'stream log + progress notifications') contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and an output schema exists, so return values need not be described. Still, for a tool with no annotations and two undocumented parameters, the description does not fully equip an agent to call it correctly; parameter behavior and usage context remain underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters, but it does not. 'Delay' and 'steps' remain unexplained in terms of units, defaults, acceptable ranges, or effect on the simulation, beyond the vague phrase 'bounded work'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 bounded work') and adds the observable behavior ('stream log + progress notifications'). It is clearly distinct from the sibling tools (text summarization, file review, filesystem reads, server info), though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool, when not to use it, or what alternatives exist. The agent must infer from the name that it is a simulation/demo tool, and there is no mention of prerequisites or intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a text file, only if it lies inside a tenant-granted workspace root.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; 'Read' does signal a non-mutating operation and the root-scoping constraint is valuable access context. But it is silent on what happens when the path falls outside the root (error? exception? empty result?) and on handling of large or non-text files, which are the main behavioral risks for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly constructed sentence with the security constraint front-loaded right after the operation. Nothing redundant and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers the operation plus the key access restriction. The remaining gap is path-format and out-of-root failure behavior, which matters for a single required parameter tool but is a modest omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'path' parameter, so the description has to compensate and only partially does: it implies the path is workspace-root-relative and constrained to granted roots, but never states whether it must be absolute or relative, nor its format. This narrows the ambiguity without resolving it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ('Read') with a specific resource ('a text file') and adds a scope qualifier (tenant-granted workspace root), which separates it from siblings like list_root_files and search_in_roots. It never names those alternatives explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'only if it lies inside a tenant-granted workspace root' functions as a precondition for use, which is genuine guidance. However, there is no statement of when to prefer this over summarize_text or review_file for the same file, so the routing decision is left implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from a tenant workspace, then have the client's LLM review it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 reveals that the client's LLM reviews the file, but does not state whether the operation is read-only, what permissions are required, whether LLM invocation has cost or latency implications, or what happens to the file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the action front-loaded and no filler. It is appropriately concise, though its brevity contributes to gaps covered in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the LLM invocation behavior, lack of annotations, and one undocumented parameter, the description is not complete enough. It omits important context about permissions, cost/side effects, and how the path is interpreted, even though an output schema exists to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'path', and schema description coverage is 0%, so the description must compensate. It adds only that the file is from a tenant workspace, without explaining path format, root resolution, or how it relates to sibling file tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Read a file') plus an additional behavior ('have the client's LLM review it'), and scopes it to a tenant workspace. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like read_root_file or summarize_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives such as read_root_file, summarize_text, or search_in_roots. The description implies a review use case but does not state exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bounded, non-symlink files in tenant-granted workspace roots.
| Name | Required | Description | Default |
|---|---|---|---|
| glob | No | *.py | |
| query | Yes | ||
| max_hits | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose useful scoping traits ('bounded', 'non-symlink', 'tenant-granted roots'), but omits whether the operation is read-only, whether it is regex or substring matching, what happens at the default max_hits, or any permission/rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is efficiently structured; the problem is under-specification, not verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, but with no annotations and 0% schema coverage the description leaves the agent without the matching semantics, default behavior, or result-limit behavior needed to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description says nothing about the three parameters. The required 'query' is unexplained (content vs filename), the 'glob' default of *.py is never mentioned, and 'max_hits' is not addressed, so the description adds almost no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (search) and resource scope (files in tenant-granted workspace roots), which is more than a tautology. However, it never says whether the search matches file contents, filenames, or globs, so the agent cannot tell what the query is actually run against, nor how this differs from list_root_files or review_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no named alternative, even though siblings like list_root_files and read_root_file plausibly overlap. The agent must infer the use case entirely from the tool name and the word 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report transport configuration and negotiated client capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. "Report" strongly implies a read-only, side-effect-free operation, but the description does not explicitly state side effects, permissions, or whether invoking it has any impact. For a zero-parameter diagnostic tool this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words and the purpose front-loaded. It is appropriately sized for a zero-parameter diagnostic tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description needn't document inputs or return fields. However, it could better state when to use this tool and what kind of information the report contains, so completeness is adequate but not strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and none are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Report") and names concrete resources: transport configuration and negotiated client capabilities. It is clearly a diagnostic server-info tool and does not overlap with the sibling content/file tools, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no explicit guidance on when to call this tool versus alternatives, nor any prerequisites or exclusions. The diagnostic purpose is implied, but an agent must infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize text using the client's language model (MCP sampling).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| max_words | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it does disclose the important mechanism: summarization is delegated to the client's LLM via MCP sampling, which implies sampling support is required and that the output is model-generated rather than deterministic. It omits cost/latency implications, failure behavior when sampling is unavailable, and any input length limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, and the distinguishing mechanism is stated inline. It is efficient, though brevity here shades into under-specification rather than crisp completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be described. However, for a two-parameter tool with 0% schema coverage and no annotations, the description leaves max_words semantics, input sizing, and sampling-failure behavior unexplained, so it is only marginally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, yet it never mentions 'text' or 'max_words' (which defaults to 80). The only hint of output control is the implicit notion of a summary, leaving the meaning of max_words and any text constraints undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Summarize text') and adds the notable mechanism ('client's language model (MCP sampling)'), which no sibling tool covers. Clear enough to distinguish from review_file or read_root_file, though it doesn't say what kind of summary (length, style) results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this versus the other file-oriented siblings, nor any prerequisite such as the client needing to support sampling. The agent must infer all usage context from the single word 'Summarize'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0list_root_fileslong_running_taskread_root_filereview_filesearch_in_rootsserver_infosummarize_textScored across 7 tools
Most tools have clearly distinct purposes: file listing, reading, searching, text summarization, file review, long-running task simulation, and server info. There is minor overlap between read_root_file and review_file, and between summarize_text and review_file, since both review_file and summarize_text invoke the client LLM on content.
The action-oriented tools mostly follow a predictable verb_noun pattern: summarize_text, review_file, list_root_files, read_root_file, search_in_roots. The exceptions are long_running_task and server_info, which are noun phrases rather than verb-led names, but they remain readable and understandable.
Seven tools is a well-scoped set for a platform demonstrating text processing, file/root operations, long-running work, and server metadata. Each tool appears to earn its place without excessive breadth.
The surface covers read-only workspace operations, LLM-based summarization/review, task progress streaming, and server introspection, which fits the apparent tenant-root read-only model. Minor gaps exist around explicit task lifecycle management or write operations, but these may be intentionally out of scope for a roots-based platform.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Persistent cloud workspaces for AI agents: run commands, edit files, use git and a browser.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Context and control for any AI. Agent identity, scoped access, and proof across tools.
