Spaces:
Running
Running
Commit
Β·
b314aa2
1
Parent(s):
b56b560
Enhance README with detailed workflow and step-by-step instructions for API monitoring
Browse files
README.md
CHANGED
@@ -21,6 +21,10 @@ tags:
|
|
21 |
|
22 |
Hermes is a tool designed to automate the monitoring of REST API endpoints. It allows users to input their API configurations and monitor the responses over time, allowing for both data collection/tracking and API performance analysis.
|
23 |
|
|
|
|
|
|
|
|
|
24 |
## Who are we? Why did we build this?
|
25 |
|
26 |
We're a team of 4 late-second/early-third-year CS students. This hackathon was most of us's first time working with a lot of the technologies we used, such as database management, servers, and hosting. We decided to build Hermes since a lot of us realized that there wasn't really a good way to monitor APIs, at least not without a lot of manual work. We wanted to build a tool that would allow users to easily do this, no matter what it may be used for. We also wanted to build something that would allow us to learn more about the technologies we were using, and we definitely did that!
|
@@ -37,6 +41,88 @@ Hermes requires users to generate an MCP API key, which you can do right [here a
|
|
37 |
|
38 |
Call results and configurations will be deleted 14 days after the last call to the API. This is to ensure that the database does not get too large and to protect user privacy.
|
39 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
40 |
## Problems we ran into
|
41 |
|
42 |
Since (free) Gradio is stateless, we had to find a way to pass down information between both the different API calls and the user calls, while still ensuring privacy. We ended up using the MCP API key as a user identifier, which allowed us to separate user data while still being able to access it when needed.
|
|
|
21 |
|
22 |
Hermes is a tool designed to automate the monitoring of REST API endpoints. It allows users to input their API configurations and monitor the responses over time, allowing for both data collection/tracking and API performance analysis.
|
23 |
|
24 |
+
## What does it do?
|
25 |
+
|
26 |
+
This is meant to be an MCP tool, which means that it can be used by agents (like Claude) to monitor APIs (It can be used by humans too, especially to view the data, but it is primarily designed for agents). It allows users to input any API configuration and monitor the responses over time. The tool can validate the API configuration, activate monitoring, and retrieve monitored data in different formats (summary, details, or full). This makes it easy to track API performance and analyze the data collected.
|
27 |
+
|
28 |
## Who are we? Why did we build this?
|
29 |
|
30 |
We're a team of 4 late-second/early-third-year CS students. This hackathon was most of us's first time working with a lot of the technologies we used, such as database management, servers, and hosting. We decided to build Hermes since a lot of us realized that there wasn't really a good way to monitor APIs, at least not without a lot of manual work. We wanted to build a tool that would allow users to easily do this, no matter what it may be used for. We also wanted to build something that would allow us to learn more about the technologies we were using, and we definitely did that!
|
|
|
41 |
|
42 |
Call results and configurations will be deleted 14 days after the last call to the API. This is to ensure that the database does not get too large and to protect user privacy.
|
43 |
|
44 |
+
## π Complete Workflow Process
|
45 |
+
|
46 |
+
### Prerequisites
|
47 |
+
|
48 |
+
- **Get your MCP API Key**: Visit [https://mcp-hackathon.vercel.app/main](https://mcp-hackathon.vercel.app/main) to generate your unique API key
|
49 |
+
- **Have your API details ready**: Know the endpoint you want to monitor, required parameters, headers, and authentication
|
50 |
+
|
51 |
+
### Step-by-Step Process (For Humans)
|
52 |
+
|
53 |
+
#### **Step 1: Validate & Configure**
|
54 |
+
|
55 |
+
Use the `validate_api_configuration` function to:
|
56 |
+
|
57 |
+
- Test your API endpoint to ensure it works
|
58 |
+
- Verify the response contains the data you expect
|
59 |
+
- Store the configuration if validation passes
|
60 |
+
|
61 |
+
**What you need:**
|
62 |
+
|
63 |
+
- Your MCP API key
|
64 |
+
- API details (URL, method, parameters, headers)
|
65 |
+
- Monitoring schedule (how often to check, for how long)
|
66 |
+
|
67 |
+
**What you get:**
|
68 |
+
|
69 |
+
- A `config_id` (save this - you'll need it for the next steps!)
|
70 |
+
- Sample response to verify the data is what you expect
|
71 |
+
- Confirmation that your API configuration is valid
|
72 |
+
|
73 |
+
#### **Step 2: Activate Monitoring**
|
74 |
+
|
75 |
+
Use the `activate_monitoring` function to:
|
76 |
+
|
77 |
+
- Start the automated monitoring process
|
78 |
+
- Begin collecting data at your specified intervals
|
79 |
+
|
80 |
+
**What you need:**
|
81 |
+
|
82 |
+
- The `config_id` from Step 1
|
83 |
+
- Your MCP API key
|
84 |
+
|
85 |
+
**What happens:**
|
86 |
+
|
87 |
+
- Background monitoring starts immediately (or at your scheduled time)
|
88 |
+
- API calls are made automatically at your specified intervals
|
89 |
+
- All responses are stored in the database
|
90 |
+
|
91 |
+
#### **Step 3: Retrieve Data**
|
92 |
+
|
93 |
+
Use the `retrieve_monitored_data` function to:
|
94 |
+
|
95 |
+
- Check monitoring status and progress
|
96 |
+
- Get collected data in your preferred format
|
97 |
+
|
98 |
+
**What you need:**
|
99 |
+
|
100 |
+
- The `config_id` from Step 1
|
101 |
+
- Your MCP API key
|
102 |
+
- Data mode preference:
|
103 |
+
- `summary`: Quick overview with recent results (best for LLMs)
|
104 |
+
- `details`: Full API responses with minimal metadata
|
105 |
+
- `full`: Complete data including all metadata and debug info
|
106 |
+
|
107 |
+
### Example Workflow
|
108 |
+
|
109 |
+
```md
|
110 |
+
1. You want to monitor a weather API every 30 minutes for 2 hours
|
111 |
+
β
|
112 |
+
2. Call validate_api_configuration() with your weather API details
|
113 |
+
β Returns: config_id = 123456
|
114 |
+
β
|
115 |
+
3. Review the sample response - looks good!
|
116 |
+
β
|
117 |
+
4. Call activate_monitoring(config_id=123456, mcp_api_key="your_key")
|
118 |
+
β Monitoring starts immediately
|
119 |
+
β
|
120 |
+
5. Wait for data collection (or check progress anytime)
|
121 |
+
β
|
122 |
+
6. Call retrieve_monitored_data(config_id=123456, mode="summary")
|
123 |
+
β Get your weather monitoring results!
|
124 |
+
```
|
125 |
+
|
126 |
## Problems we ran into
|
127 |
|
128 |
Since (free) Gradio is stateless, we had to find a way to pass down information between both the different API calls and the user calls, while still ensuring privacy. We ended up using the MCP API key as a user identifier, which allowed us to separate user data while still being able to access it when needed.
|