Skip to main content
Glama
Sign In
mcp-builder-mcp

mcp-builder-mcp

by Charley-Forey-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mcp-server-demo

MCP server with OpenAPI validation and analysis tools.

Running the server

Run: uv run python main.py

This starts the server on streamable-http at http://127.0.0.1:8000/mcp. It works locally and behind ngrok or other tunnels with no extra commands or env vars. For Cursor/stdio, use: uv run python main.py stdio.

The validate_openapi tool accepts file paths, inline JSON/YAML, or any public URL. The tool fetches and reads the content over HTTP (no manual download required). Supported URL types include: raw file URLs (e.g. raw.githubusercontent.com/.../ProjectSight-v1.json), Google Drive view or direct download links, and any other public URL that returns JSON or YAML. Both “read the page” and “download” semantics work: the tool GETs the URL and parses the response body.

After validation, the prompt_mcp_developer_context tool provides Trimble Agentic Ecosystem context, an inferred market segment and intended end users from the API, and two prompts for the agent creator: (1) the job role of the person adding MCP tools for this API, and (2) the task/workflow/job the agent being created will aid in. Pass either the analysis from validate_openapi (when valid) or openapi_input (URL/path/inline) to get these prompts.

Available Tools

9 tools
generate_mcp_serverA

Step 5 of 6. Generate a complete MCP server directory from the selected endpoints.

Requires step 4 (select_endpoint_bundle). Uses stored validated_spec and selected_endpoints. output_dir: optional path where to create the project (e.g. ./output/projectsight-mcp). repo_name: optional suggested repo name for step 6; if omitted, derived from API title.

If scaffold succeeds, automatically proceeds to step 6: creates a new public GitHub repo, uploads the directory, and returns repo_url. Always a new repo, always public. Returns: output_dir, files_created, tool_count, repo_url (if upload succeeded), next_step_guidance.

Inputs: output_dir, repo_name.

get_workflow_statusA

Return the current workflow step and the required order of tools.

Use this to keep the user/agent on track. Order: 1. validate_openapi → 2. prompt_mcp_developer_context → 3. propose_endpoint_bundles → 4. select_endpoint_bundle → 5. generate_mcp_server → 6. upload_to_github.

Inputs: no named parameters.

prompt_mcp_developer_contextA

Step 2 of 6. Use after validate_openapi to get Trimble Agentic Ecosystem context and prompts.

Requires step 1 (validate_openapi). Uses stored analysis from step 1 if neither analysis nor openapi_input is provided. Otherwise provide analysis (from validate_openapi) or openapi_input.

Returns: context, api_summary, inferred_market_segment_and_users, prompts_to_user. Completes workflow step 2. Next: run propose_endpoint_bundles (step 3).

Inputs: analysis, openapi_input, input_type.

propose_endpoint_bundlesA

Step 3 of 6. Propose three endpoint bundles (Green / Yellow / Red) based on the API and optional user context.

Requires step 2 (prompt_mcp_developer_context). Uses stored spec and inferred_segment from prior steps if not provided. Otherwise provide spec or openapi_input; optional agent_creator_role, agent_task_workflow, inferred_segment.

Returns: bundles (green, yellow, red) with endpoint_count and endpoints_sample; dependency_endpoints; total_operations. Completes workflow step 3. Next: run select_endpoint_bundle(choice) (step 4).

Inputs: analysis, openapi_input, input_type, spec, +3 more.

reset_workflowA

Clear workflow state and start over. Call this when the user wants to use new API docs.

After reset, ask the user to provide new API docs (URL or path) and run validate_openapi (step 1).

Inputs: no named parameters.

select_endpoint_bundleA

Step 4 of 6. Resolve the user's selection (green | yellow | red) and optional add/remove of endpoints.

Requires step 3 (propose_endpoint_bundles). Uses stored bundles_result from step 3 if not provided. choice: "green" | "yellow" | "red". customizations: optional { "add_operation_ids": [...], "remove_operation_ids": [...] }. Returns selected endpoints with required and dependency annotations and a summary. Completes workflow step 4.

Inputs: choice (required), customizations, bundles_result, spec, +2 more.

send_repo_email_to_userA

After a successful GitHub upload, send the repo URL to the user's email via Gmail.

Call this only after the user has confirmed their email is correct. email: the user's email address (validated before sending). repo_url: optional; if omitted, uses the repo URL from the last upload (get_stored). description: optional short description to include in the email body.

Uses SENDER_EMAIL (default charles_forey@trimble.com) and GOOGLE_APP_PASSWORD from .env. Returns success or error with message.

Inputs: email (required), repo_url, description.

upload_to_githubA

Step 6 of 6. Create a new GitHub repo and upload the generated MCP server directory.

Requires step 5 (generate_mcp_server). Uses stored output_dir if source_dir not provided. repo_name: optional repo name; default unique name (base + timestamp) to avoid repeats. visibility: "public" or "private". Default: "public". source_dir: optional path to generated directory; default: get_stored("output_dir").

Returns: repo_url, message, next_step_guidance. Completes workflow step 6.

Inputs: repo_name, visibility, source_dir.

validate_openapiA

Step 1 of 6. Validates OpenAPI 2/3 specs (file path, URL, or inline JSON/YAML). URLs: any public URL that returns the spec. Fetches and reads the response body (no manual download). Works with raw file URLs (e.g. raw.githubusercontent.com/.../ProjectSight-v1.json), Google Drive view or direct links, and any other public URL; both read and download-style URLs work. Returns validation result, analysis (summary + small sample), and scaffolding (description + sample). On success: valid=True, openapi_version, analysis, scaffolding. Completes workflow step 1. On failure: valid=False, validation_errors (list of message, path, context). You must present results to the user and get confirmation before calling step 2.

Inputs: openapi_input (required), input_type.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

    TDQS

    A3.8/5.0

    Scored across 9 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose within the MCP server generation workflow. Tools like validate_openapi, propose_endpoint_bundles, and generate_mcp_server handle specific sequential steps, while utilities like get_workflow_status and reset_workflow serve unique supporting roles. There is no functional overlap between any tools.

    Naming Consistency4/5

    Most tools follow a consistent verb_noun pattern (e.g., validate_openapi, generate_mcp_server, upload_to_github). The exception is send_repo_email_to_user, which uses a verb_noun_preposition_noun structure, slightly deviating from the otherwise uniform naming convention.

    Tool Count5/5

    With 9 tools, the server is well-scoped for its purpose of guiding users through a 6-step MCP server generation process. Each tool serves a necessary role in the workflow, from validation to deployment, without redundancy or excessive fragmentation.

    Completeness5/5

    The toolset provides complete coverage of the MCP server generation lifecycle, including validation, planning, generation, deployment, and communication. It covers all essential steps from OpenAPI validation to GitHub upload and email notification, with no apparent gaps that would hinder an agent's ability to complete the workflow.

    Resources

    Related MCP Connectors