Skip to main content
Glama
riker-t

Ramp Developer MCP Server

by riker-t

submit_feedback

Submit feedback about the MCP server interface, tools, or encountered issues to help improve the developer experience.

Instructions

Submit feedback to Ramp about the MCP server interface, tools, or problems you encounter. Helps improve the developer experience.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
feedbackYesYour feedback about the MCP tools, API documentation, or any issues encountered. Must be 10-1000 characters.
tool_nameNoOptional: which tool this feedback relates to (e.g., 'validate_endpoint_usage', 'search_documentation')

Implementation Reference

  • The main handler function that validates input, calls the helper to submit feedback to Ramp's API, and returns the result or error message.
    async def execute(self, arguments: Dict[str, Any]) -> List[TextContent]:
        """Execute submit_feedback tool"""
        feedback = arguments.get("feedback", "").strip()
        tool_name = arguments.get("tool_name", "").strip()
        
        # Input validation (same as remote server)
        if len(feedback) < 10 or len(feedback) > 1000:
            return [TextContent(
                type="text",
                text="Feedback must be at least 10 characters long and less than 1000 characters."
            )]
        
        try:
            # Submit feedback to Ramp's public API (following remote server pattern)
            result = await self._submit_feedback_to_ramp(feedback, tool_name)
            return [TextContent(type="text", text=result)]
            
        except Exception as e:
            return [TextContent(
                type="text",
                text=f"Unexpected error submitting feedback: {str(e)}"
            )]
  • Input schema defining the required 'feedback' string (10-1000 chars) and optional 'tool_name'.
    @property
    def input_schema(self) -> Dict[str, Any]:
        return {
            "type": "object",
            "properties": {
                "feedback": {
                    "type": "string",
                    "description": "Your feedback about the MCP tools, API documentation, or any issues encountered. Must be 10-1000 characters."
                },
                "tool_name": {
                    "type": "string", 
                    "description": "Optional: which tool this feedback relates to (e.g., 'validate_endpoint_usage', 'search_documentation')"
                }
            },
            "required": ["feedback"]
        }
  • src/server.py:46-51 (registration)
    Registration of the SubmitFeedbackTool instance in the server's list of tools, which is used by list_tools() and call_tool().
    tools = [
        PingTool(),
        SearchDocumentationTool(knowledge_base),
        SubmitFeedbackTool(),
        GetEndpointSchemaTool(knowledge_base)
    ]
  • Private helper method that performs the HTTP GET request to Ramp's feedback API endpoint with error handling for various HTTP and network issues.
    async def _submit_feedback_to_ramp(self, feedback: str, tool_name: str = "") -> str:
        """Submit feedback to Ramp's public feedback API"""
        
        # Determine environment URL (defaulting to production like remote server)
        base_url = "https://api.ramp.com"  # Production by default
        
        # Build request parameters (same as remote server)
        params = {
            "feedback": feedback,
            "source": "RAMP_MCP"  # Use approved source value (API only accepts RAMP_MCP or API_DOCS)
        }
        
        # Note: tool_name is captured for user context but not sent to API
        # (API only accepts feedback and source parameters)
            
        try:
            async with httpx.AsyncClient(timeout=30.0) as client:
                response = await client.get(
                    f"{base_url}/v1/public/api-feedback/llm",
                    params=params
                )
                response.raise_for_status()
                
                # Success message with tool context
                success_msg = "Feedback submitted successfully"
                if tool_name:
                    success_msg += f" (regarding {tool_name} tool)"
                success_msg += "!"
                
                return success_msg
                
        except httpx.HTTPStatusError as e:
            if e.response.status_code == 400:
                return "Invalid feedback format. Please check your message and try again."
            elif e.response.status_code >= 500:
                return "Ramp's feedback service is temporarily unavailable. Please try again later."
            else:
                return f"HTTP error {e.response.status_code}. Please try again later."
                
        except httpx.TimeoutException:
            return "Request timed out. Please check your internet connection and try again."
            
        except httpx.RequestError:
            return "Network error. Please check your internet connection and try again."
  • src/server.py:29-29 (registration)
    Import of SubmitFeedbackTool from the tools module to enable server registration.
    from tools import PingTool, SearchDocumentationTool, SubmitFeedbackTool, GetEndpointSchemaTool
Behavior2/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 mentions the tool 'helps improve the developer experience' but doesn't disclose behavioral traits like whether submission is anonymous, requires authentication, has rate limits, or provides confirmation. For a feedback tool with zero annotation coverage, this leaves significant gaps in understanding how it operates beyond the basic action.

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 concise sentences with zero waste: the first specifies the action and scope, and the second states the purpose. It's front-loaded with the core function and appropriately sized, making it easy to scan and understand quickly.

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?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and general usage but lacks details on behavioral aspects like response handling or error conditions. Without annotations or output schema, more context on what happens after submission would enhance completeness for a feedback tool.

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 the schema fully documents both parameters ('feedback' and 'tool_name') with descriptions and constraints. The description adds no additional meaning beyond what the schema provides, such as examples of feedback content or how 'tool_name' relates to sibling tools. Baseline 3 is appropriate when schema does the heavy lifting.

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 action ('submit feedback') and target ('to Ramp about the MCP server interface, tools, or problems'), with a specific purpose ('Helps improve the developer experience'). It distinguishes from siblings like 'get_endpoint_schema' or 'search_documentation' by focusing on feedback submission rather than information retrieval. However, it doesn't explicitly contrast with 'ping' (which tests connectivity), leaving minor ambiguity.

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 feedback on 'MCP server interface, tools, or problems,' providing general context. It doesn't specify when NOT to use it (e.g., for technical support vs. bug reports) or name explicit alternatives among siblings. Guidelines are present but lack detailed exclusions or comparative advice, relying on implied understanding.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/riker-t/ramp-dev-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server