Click on "Install 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., "@Rumble MCP show me the latest fundamental calls"
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.
⚠️ Disclaimer: This tool requires a valid subscription to TheRumble.app. It is intended for personal use only. Any misuse of this tool is not the responsibility of the developer. By using this tool, you agree to comply with TheRumble's terms of service.
An MCP (Model Context Protocol) server that provides AI assistants with access to TheRumble.app investment research data for the Egyptian stock market (EGX).
Related MCP server: Tapetide MCP Server
Feature | Description |
📈 Fundamental Calls | Long-term investment recommendations with target prices, analyst ratings, and performance metrics |
📊 Technical Calls | Short-term trading signals with entry, target, and stop-loss prices |
🏆 Track Records | Historical performance and alpha vs EGX30 benchmark |
📋 Asset Lists | Curated portfolios: RFP, Bottom Fisher, and RSP |
npx rumble-mcpnpm install -g rumble-mcpgit clone https://github.com/AndrewHossam/rumble-mcp.git
cd rumble-mcp
npm install && npm run build
npm link # Makes 'rumble-mcp' globally availableTheRumble uses Firebase authentication. To prevent your token from expiring every hour, you should use both an ID token and a Refresh token.
Run the helper script to get both:
npx rumble-mcp extract-token
# OR inside the project
npm run extract-tokenPaste the generated script into your browser console on therumble.app. It will give you the .env content to copy.
Why use a refresh token?
Without it: Credentials expire in 1 hour
With it: The MCP auto-refreshes your session indefinitely 🚀
Click the Install in VS Code button above, or
Open Settings (Cmd+,) → search "MCP" → Add server configuration:
{
"mcp": {
"servers": {
"rumble": {
"command": "npx",
"args": ["rumble-mcp"],
"env": {
"RUMBLE_FIREBASE_TOKEN": "your_firebase_token",
"RUMBLE_REFRESH_TOKEN": "your_refresh_token",
"RUMBLE_MARKET": "EGY"
}
}
}
}
}Click the Install in Cursor button above, or
Go to Settings → MCP Servers → Add:
{
"rumble": {
"command": "npx",
"args": ["rumble-mcp"],
"env": {
"RUMBLE_FIREBASE_TOKEN": "your_firebase_token",
"RUMBLE_REFRESH_TOKEN": "your_refresh_token",
"RUMBLE_MARKET": "EGY"
}
}
}Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"rumble": {
"command": "npx",
"args": ["rumble-mcp"],
"env": {
"RUMBLE_FIREBASE_TOKEN": "your_firebase_token",
"RUMBLE_REFRESH_TOKEN": "your_refresh_token",
"RUMBLE_MARKET": "EGY"
}
}
}
}claude mcp add rumble -- npx rumble-mcpThen set your tokens:
export RUMBLE_FIREBASE_TOKEN="your_firebase_token"
export RUMBLE_REFRESH_TOKEN="your_refresh_token"
export RUMBLE_MARKET="EGY" # Optional, defaults to EGYMost MCP-compatible clients follow a similar pattern:
{
"name": "rumble",
"command": "npx",
"args": ["rumble-mcp"],
"env": {
"RUMBLE_FIREBASE_TOKEN": "your_firebase_token",
"RUMBLE_REFRESH_TOKEN": "your_refresh_token",
"RUMBLE_MARKET": "EGY"
}
}Tool | Category | Description |
| Discovery | List active fundamental investment calls |
| Discovery | List active technical trading calls |
| Details | Get full details for any call (fundamental/technical) by ID |
| Insights | Fundamental track record (avg return, alpha vs index, holding period) |
| Insights | Technical track record (hit ratio, avg win/loss, holding period) |
| Insights | Latest content releases |
| Portfolios | Rumble Fundamental Portfolio (long-term picks) |
| Portfolios | Bottom Fisher Portfolio (undervalued stocks) |
| Portfolios | Rumble Shariah Portfolio (Shariah-compliant) |
| Portfolios | List all known portfolio aliases |
get_call_details UsageParameters: callId (required), type (optional: fundamental/technical), sections (optional: ["story", "performance", "updates"])
Example:
{"callId": "call_id_here", "sections": ["performance", "updates"]}Once configured, ask your AI assistant:
"What are the current active fundamental calls on Rumble?"
"Get full details for call_id_here"
"Show me just the performance and updates for that symbol"
"Get the Bottom Fisher portfolio"
Variable | Required | Description |
| ✅ Yes | Your Firebase ID token from therumble.app |
| Recommended | Firebase refresh token for automatic token renewal |
| No | Market code (default: |
| No | Stable device ID for request headers (auto-generated if omitted) |
| No | Stable session ID for request headers (auto-generated if omitted) |
| No | Public Firebase Web API key for token refresh (falls back to the built-in default) |
# Clone and setup
git clone https://github.com/AndrewHossam/rumble-mcp.git
cd rumble-mcp
npm install
# Development mode (hot reload)
npm run dev
# Build for production
npm run build
# Run tests
npm testThis project includes automated safety checks to prevent breaking changes:
Pre-commit Hooks: Automatically builds the project before every commit to catch syntax and type errors.
CI/CD: GitHub Actions automatically verifies builds and types on every push and pull request.
Publish Safety: The project is locked to automatically run a fresh build before npm publish to ensure users always get the latest code.
If you find this MCP useful, consider supporting the project:
Support via TipTea (Egypt Local: InstaPay / Vodafone Cash)
MIT © 2026
Get a curated portfolio/asset list from TheRumble by ID or alias.
| Name | Required | Description | Default |
|---|---|---|---|
| listId | Yes | Asset list ID or alias (rfp-egx, bottom-fisher, rsp-egx) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose read-only nature, authentication requirements, error behavior, or any side effects. 'Get' implies safe read but not stated.
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?
Single clear sentence, front-loaded, no unnecessary words. Every word adds value.
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?
For a simple one-parameter retrieval tool, the description covers the core purpose and parameter meaning. Absence of output schema is acceptable per rules, but a bit more context on return value (e.g., 'returns a list of asset identifiers') would improve it.
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 100% (param listId with examples). Description adds 'by ID or alias', which is redundant with schema's alias examples. No extra semantics beyond 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?
Clear verb ('Get') and resource ('curated portfolio/asset list') and source ('from TheRumble'). But doesn't explicitly differentiate from sibling tools like 'get_rfp_portfolio' or 'get_bottom_fisher_portfolio', which seem to fetch specific portfolios by name.
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 guidance on when to use this tool versus siblings. No mention of prerequisites, context, or alternatives. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Bottom Fisher Portfolio - Undervalued stocks with high upside potential.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states it 'gets' a portfolio. It does not mention read-only nature, potential authentication needs, data freshness, or any side effects, providing minimal transparency.
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 very concise (10 words) but lacks necessary detail for a tool with many siblings. While the sentence is efficient, it sacrifices completeness and clarity, earning a middling score.
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 tool has no parameters or output schema and multiple sibling tools, the description should explain the portfolio's nature and when to use it. It only names the portfolio and its theme, leaving the agent without enough context to decide.
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?
Since the tool has zero parameters, the baseline score is 4 per instructions. The description correctly implies no input is needed, and the schema confirms this, so no additional parameter semantics are required.
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 'Get the Bottom Fisher Portfolio - Undervalued stocks with high upside potential', which clearly identifies the tool as retrieving a specific portfolio and gives its investment theme. However, it does not differentiate from sibling portfolio tools like get_rfp_portfolio or get_rsp_portfolio, limiting distinction.
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 guidance is provided on when to use this tool over alternatives. There is no mention of use cases, prerequisites, or comparison with other portfolio tools, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific investment call (fundamental or technical).
Returns comprehensive data including:
Basic info: ID, title, status, action/recommendation
Asset: Stock symbol (ticker), company name, industry, icon
Prices: Start/current/target prices, buy range (for technical)
Story: Full investment thesis and analysis
Performance: Current price vs start, remaining upside
Updates: Historical updates and revisions from analysts
Use the 'sections' parameter to filter which data to return.
| Name | Required | Description | Default |
|---|---|---|---|
| callId | Yes | The call ID (e.g., "0c76e268-80df-4ab2-aaf7-a8a4dcc82b28") | |
| type | No | Type of call. If not provided, will try fundamental first then technical. | |
| sections | No | Which sections to include. If not provided, returns all sections. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains what data is returned and mentions filtering via the 'sections' parameter. Lacks disclosure of side effects or auth needs, but as a read-only tool, this is acceptable.
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?
Description is structured with a clear purpose and bullet points. Slightly verbose but front-loaded with important information. Could be more concise, but remains effective.
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?
For a tool with 3 parameters and no output schema, the description adequately explains return data and filtering. Lacks error handling or rate limit info, but is complete for typical use.
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 100%. Description adds value by providing an example for callId, explaining default behavior for type, and clarifying how sections filter results. Enhances schema meaning.
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?
Clearly states it retrieves detailed information about a specific investment call. The description lists the categories of data returned, distinguishing it from sibling tools that focus on lists or portfolios.
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?
Describes the tool's purpose without explicitly stating when not to use it. However, the sibling tool names imply this tool is for single-call details, providing implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of active fundamental investment calls from TheRumble. Returns stock recommendations with target prices, performance, and analyst info. Use get_call_details for full details on a specific call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of calls to return | |
| skip | No | Number of calls to skip for pagination | |
| market | No | Market code (default: EGY for Egypt) | EGY |
| status | No | Filter by call status | active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It correctly describes the tool as returning a list of calls, but does not disclose behavioral traits such as rate limits, authentication requirements, or the read-only nature of the operation. The description is accurate but lacks depth.
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 concise with only two sentences, front-loading the purpose and then providing details and a pointer to an alternative tool. No superfluous information.
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 four parameters with good schema descriptions and no output schema, the description sufficiently explains the tool's function and return data. It could mention pagination or ordering but is largely complete for its complexity.
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 input schema has 100% description coverage, so the baseline is 3. The description does not add additional parameter-level meaning beyond what is already in the 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 clearly states the tool retrieves a list of active fundamental investment calls from TheRumble and specifies the returned data (stock recommendations, target prices, etc.). It distinguishes itself from the sibling tool 'get_call_details' which is for full details on a specific call.
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 description explicitly states when to use this tool (to get a list) and when to use the alternative 'get_call_details' (for full details on a specific call). However, it does not mention other sibling tools or provide exclusions for them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the overall track record for fundamental calls, including average return, alpha vs benchmark, and hit ratio.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Market code (default: EGY for Egypt) | EGY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes the output metrics but does not disclose any behavioral traits like data freshness, aggregation scope, or side effects. Acceptable for a read operation.
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?
Single sentence, front-loaded, and direct. Very concise but could benefit from a bit more structure (e.g., listing outputs separately).
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?
No output schema, but description lists key return metrics. Missing details like time period or aggregation logic. Adequate for a simple retrieval tool.
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 100% and includes description for the single parameter. The tool's description does not add further meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 clearly states it retrieves the track record for fundamental calls, listing specific metrics (average return, alpha, hit ratio). It distinguishes from siblings like 'get_technical_track_record' and 'get_fundamental_calls'.
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 explicit guidance on when to use or not use the tool, nor mention of alternatives. However, the description clearly implies its purpose, so it is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest content releases and updates for fundamental calls.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Market code (default: EGY for Egypt) | EGY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only operation ('Get'). However, it does not disclose any behavioral traits beyond the basic action, such as whether it requires authentication or if it has rate 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?
The description is a single, direct sentence with no extraneous words. It is appropriately concise, though adding a brief clarification about 'fundamental calls' could improve usefulness without much length.
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 tool's low complexity (one optional parameter, no output schema), the description is minimally adequate. It explains the purpose but lacks details about the returned data structure or the meaning of 'fundamental calls'.
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 100%, so the input schema already documents the 'market' parameter. The description adds no additional meaning or context beyond what the schema provides, meeting the baseline.
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 clearly states the verb 'Get' and the resource 'latest content releases and updates for fundamental calls'. It partially distinguishes from siblings like 'get_fundamental_calls' by focusing on releases/updates rather than the calls themselves, though 'fundamental calls' could be more explicitly defined.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention any prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Rumble Fundamental Portfolio (RFP) - Long-term investment picks based on fundamental analysis for the Egyptian market.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the tool returns investment picks, implying a read operation. No side effects or other behaviors are mentioned, but the tool is simple with no parameters.
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 concise sentence that efficiently communicates purpose and scope with no extraneous words.
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?
For a tool with no parameters, no output schema, and simple purpose, the description fully explains what the tool provides. No additional context is necessary.
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 baseline is 4. The description does not need to add parameter meaning.
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 clearly identifies the resource (Rumble Fundamental Portfolio), states the action (Get), and distinguishes it from siblings by specifying the portfolio type and market focus (Egyptian market).
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 description implies use for long-term fundamental Egyptian market picks but provides no explicit guidance on when to use this tool versus siblings like get_rsp_portfolio or get_bottom_fisher_portfolio.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Rumble Shariah Portfolio (RSP) - Shariah-compliant stocks handpicked for the Egyptian market.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, requires authorization, or any side effects, missing a critical opportunity to inform the agent.
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, clear sentence with no extraneous information. Every word is earned, making it highly concise and easy to parse.
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 no output schema, the description should indicate the return format (e.g., list of stocks). It does not, leaving uncertainty. However, the tool is simple with no parameters, so the gap is partially mitigated.
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 tool has zero parameters and 100% schema coverage, so the parameter burden is minimal. The description adds no param information, but none is needed, warranting a baseline score of 4.
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 clearly states the tool retrieves the Rumble Shariah Portfolio (RSP), a specific resource (Shariah-compliant stocks for Egypt), and distinguishes it from sibling tools like get_rfp_portfolio through naming.
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 explicit when-to-use or when-not-to-use guidance is provided. The context is implied by the name and description, but alternatives like get_rfp_portfolio are not compared, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of active technical trading calls from TheRumble. Returns short-term trading signals with entry range, target prices, and expert info. Use get_call_details for full story and updates on a specific call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of calls to return | |
| skip | No | Number of calls to skip for pagination | |
| market | No | Market code (default: EGY for Egypt) | EGY |
| status | No | Filter by call status | active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read-only nature, rate limits, or scalability. As a list tool, it's assumed safe, but lacks explicit transparency.
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?
Two sentences, front-loaded with purpose and output, and efficiently directs to alternative. No fluff or redundancy.
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?
Covers main function and return fields. Could optionally mention pagination behavior or default sorting, but given simplicity and no output schema, it's reasonable.
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 100%, so parameters are fully described in the input schema. The tool description adds no additional semantic information about parameters.
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 clearly states it retrieves a list of active technical trading calls, listing specific return fields (entry range, target prices, expert info), and distinguishes from sibling tool get_call_details.
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?
Directly suggests using get_call_details for full details on a specific call, providing guidance on when to use alternative. Could be improved by noting when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the overall track record for technical calls, including hit ratio, average win/loss, and holding period.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Market code (default: EGY for Egypt) | EGY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only lists output fields but does not mention side effects, read-only status, data freshness, or required permissions. Minimal transparency beyond basic purpose.
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 that efficiently conveys the tool's purpose and output. No extraneous words, earning the highest score for clarity and brevity.
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 tool's simplicity (one optional param, no output schema), the description covers the basic purpose and key output fields. However, it lacks details on the return format, time range, or aggregation method, leaving some gaps for an agent to infer.
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 schema provides 100% coverage for the single parameter 'market', including a description and default. The tool's description does not add any additional meaning to the parameter, meeting the baseline for adequate documentation.
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 clearly states the tool gets the overall track record for technical calls, specifying included metrics (hit ratio, average win/loss, holding period). This distinguishes it from siblings like get_technical_calls and get_fundamental_track_record.
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 guidance is provided on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all known curated portfolio IDs and their descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides only minimal behavior (listing); no mention of side effects, access, or limitations.
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?
Single concise sentence with no wasted words, front-loading the key action and result.
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?
For a parameterless list tool, the description adequately states output; could briefly mention use case but sufficient given simplicity.
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?
No parameters exist, and the schema already covers this fully; the description adds no extra parameter info but is not needed.
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 clearly states the action (list) and resource (known curated portfolio IDs and descriptions), and it distinguishes from sibling tools that retrieve specific portfolios.
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 guidance on when to use this tool versus alternatives; no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct asset or call type: portfolios, fundamental vs technical calls, track records, releases, and details. No two tools overlap in purpose, making selection unambiguous.
All tool names follow a consistent 'get_<descriptive_noun>' pattern using snake_case. This predictability aids agent understanding and selection.
With 11 tools covering portfolios, calls, track records, releases, and details, the count is well within the ideal 3-15 range and matches the server's financial analysis scope.
The tool set provides a full read-only surface: listing known portfolios, retrieving specific portfolios or asset lists, listing fundamental and technical calls with details, track records, and latest updates. No obvious gaps for consuming investment research.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Portfolio analytics + US-equity market research for AI clients. ChatGPT deep-research compat.
Provide AI assistants with real-time access to official SEC EDGAR filings and financial data. Enab…
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Investment research superagent: podcasts, SEC filings, and no-code research pipelines.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AndrewHossam/rumble-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
