mcp-builder-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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). |
| 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. |
| 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). |
| 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). |
| 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. |
| 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. |
| 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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
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.
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.
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.
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.