xDEO — Earnings Oracle
Server Details
Reputation-ranked analyst earnings estimates. Pay per call via x402 on Base.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 2.8/5 across 8 of 8 tools scored. Lowest: 1.8/5.
Tools are mostly distinct, but 'ai_thesis' and 'read_estimate' both involve reading an estimate thesis, which could cause confusion despite different focuses (AI-synthesized vs. full thesis). Other tools have clear boundaries.
Naming conventions are mixed: some follow verb_noun pattern (list_estimates, submit_estimate), while others are nouns (leaderboard, verdict) or use a prefix (ai_thesis). No single consistent pattern.
With 8 tools, the server covers the core functions of an earnings oracle without being bloated or sparse. Each tool serves a clear purpose in the workflow.
The tool set covers submission, listing, reading, AI synthesis, consensus, and post-earnings verdicts. Missing update/delete functions, but these are unnecessary for the domain. Minor gap: no search or filtering for estimates.
Available Tools
8 toolsai_thesisAInspect
AI-synthesized investment thesis for one estimate. Combines the analyst's raw thesis, their historical accuracy, and (if scored) the actual SEC filing result into a structured analysis: summary, bull/bear case, key assumptions, risks, and confidence assessment. Costs 0.75 USDC via x402. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | estimate ID | |
| payment_token | No | base64 x402 payload |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the cost (0.75 USDC via x402) and that it is not investment advice, but does not describe error behavior, rate limits, or the handling of unscored estimates.
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 two sentences long, front-loads the core purpose, and includes key details without redundancy. Every sentence 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?
Given the complexity (AI synthesis from multiple sources) and absence of an output schema, the description adequately explains the output structure (summary, bull/bear case, etc.) and mentions cost. It could be improved by clarifying the payment_token requirement in the schema.
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 baseline is 3. The description adds context about the purpose (id for estimate) and payment token requirement (x402 payload), but does not elaborate on token format or how to obtain it.
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 is an AI-synthesized investment thesis for one estimate, listing specific components. This differentiates it from sibling tools like read_estimate (raw data) and verdict (likely a final judgment), establishing a unique purpose.
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 usage for obtaining a structured analysis combining multiple data sources, but does not explicitly state when to prefer this over alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leaderboardCInspect
Global analyst reputation leaderboard. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions 'Free' indicating no cost, but fails to disclose key behaviors such as whether the tool is read-only, pagination, sorting order, or update frequency. This is insufficient for an effective tool description.
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 extremely concise but sacrifices clarity. It consists of two short fragments without a clear sentence structure. While it has no fluff, it is too brief to be informative. A good balance would include a sentence explaining the tool's action and scope.
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 one optional parameter, no output schema, and no annotations, the description is woefully incomplete. It does not explain what data the leaderboard contains, how results are ordered, or how the limit parameter affects results. This leaves the agent with insufficient information to use the tool correctly.
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 one parameter 'limit' with no description, and the tool description does not mention it. With 0% schema description coverage, the description adds no meaning beyond the bare schema. The agent has no way to know the parameter's purpose or constraints.
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 'Global analyst reputation leaderboard' clearly identifies the resource and purpose. It implicitly indicates retrieval of a leaderboard. While it lacks an explicit verb, the noun phrase is sufficiently descriptive and distinguishes from sibling tools like list_estimates or ticker_consensus which serve different data.
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 such as list_estimates or ticer_consensus. The description only states 'Free', which is not usage context. Without any context, the agent cannot determine the appropriate scenarios for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_estimatesBInspect
All estimates for a ticker. Costs 0.01 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| payment_token | No | base64 x402 payload |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost (0.01 USDC via x402), but with no annotations, other traits like idempotency or authentication are omitted. Partial 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 purpose, no wasted words. Efficiently conveys core info.
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, no return format described. Lacks details on response structure or pagination. Adequate for a simple tool but incomplete.
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 50%; description adds no parameter details. The ticker parameter is unexplained, and payment_token description is only in schema. Description does not compensate for missing schema descriptions.
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 'All estimates for a ticker', specifying the verb (list) and resource (estimates). It distinguishes from siblings like read_estimate and submit_estimate.
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 like read_estimate or ticker_consensus. Lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tickersBInspect
List all tracked tickers. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description takes full responsibility. It only mentions 'Free', which provides minimal behavioral insight. No details about side effects, data freshness, or authentication are given.
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 extremely concise: two words plus 'Free'. Every word is necessary and there is no redundancy, achieving high efficiency.
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 no output schema and no annotations, the description could explain what 'tracked tickers' means or hint at the return format. It does not, leaving an agent underinformed about the output.
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?
With zero parameters, the baseline is 4. The description does not need to add parameter semantics as there are none, so it meets expectations.
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 the resource (tracked tickers). It is specific and distinguishes itself from sibling tools, which have different purposes like submitting estimates or viewing consensus.
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. While sibling tool names hint at different functions, the description does not explicitly state when to use list_tickers instead of others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_estimateBInspect
Full thesis for one estimate. Analyst-priced x402 payment.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| payment_token | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only hints at a 'x402 payment' but fails to mention read-only nature, authentication needs, rate limits, or whether the call is destructive. The description is insufficient.
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 short (two sentences) with no fluff, but it is too minimal to be fully informative. It sets a poor trade-off between conciseness and completeness.
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 simplicity (2 params, no output schema), the description barely covers the tool's purpose. It omits return value structure, error conditions, and any preconditions. It is incomplete for confident agent usage.
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 0%, so the description must compensate. 'Full thesis for one estimate' adds context that 'id' identifies the estimate, and 'Analyst-priced x402 payment' hints at 'payment_token' purpose, but it is cryptic and incomplete.
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 full thesis for one estimate, which aligns with the tool name 'read_estimate'. However, it does not distinguish from sibling tools like 'ai_thesis' or 'list_estimates', so it lacks explicit differentiation.
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?
Implied usage is for reading a single estimate's full thesis, but no explicit when-to-use or when-not-to-use guidance is provided, nor any mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_estimateCInspect
Submit an earnings estimate (opinion). Free; reputation is the stake.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | ||
| thesis | Yes | ||
| ticker | Yes | ||
| analyst | Yes | 0x address (Base) | |
| predicted | Yes | ||
| confidence | No | ||
| price_usdc | No | ||
| fiscal_year | Yes | ||
| fiscal_period | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions 'Free' (cost) and 'reputation is the stake' (reputation risk) but does not disclose if the operation is destructive, idempotent, or what happens upon submission (e.g., confirmation, storage). The behavioral disclosure is minimal.
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 (one sentence), which is good for conciseness, but it lacks structure and does not front-load key information. It is not overly verbose, but the brevity sacrifices completeness.
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 complexity (9 parameters, 6 required, no output schema), the description is too sparse. It does not explain the submission workflow, expected returns, or how reputation is affected. The context is insufficient for an agent to use the tool effectively without additional knowledge.
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 9 parameters with only 11% description coverage (only 'analyst' has a description). The description does not explain any parameter beyond the schema. For a tool with many parameters, this is insufficient; more context is needed to guide the agent on how to fill each field.
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 'Submit an earnings estimate (opinion)' clearly states the verb and resource. It also mentions 'Free; reputation is the stake' adding context. However, it does not explicitly differentiate from sibling tools like 'list_estimates' or 'read_estimate', but those are read-only, so the distinction is implicit.
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 provides no guidelines on when to use this tool versus alternatives, no prerequisites, and no context for required reputation. The phrase 'reputation is the stake' hints at a requirement but is vague. No when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ticker_consensusCInspect
Ticker details + free reputation-weighted consensus estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Tool Definition Quality
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 'free reputation-weighted', hinting at data quality, but does not disclose whether the tool is read-only, any side effects, rate limits, or data freshness. For a read operation, this is insufficient.
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 sentence with 9 words, making it concise. However, it lacks structure and omits important details, so it does not fully earn its place.
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 simple tool (one parameter, no output schema), the description is vague about what 'ticker details' includes and the estimate format. It leaves the agent with unanswered questions, thus incomplete.
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 0%, and the description does not explain the 'ticker' parameter at all. It fails to add meaning beyond the schema, leaving the agent to guess its purpose and format.
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 'Ticker details + free reputation-weighted consensus estimate', which identifies the tool's output. It distinguishes from siblings like submit_estimate and list_estimates, but lacks an explicit verb like 'get' or 'retrieve'.
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 such as list_estimates or verdict. The description implies it's for getting consensus but does not specify scenarios or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verdictDInspect
Post-earnings scoreboard for a filing. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| filingId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It only says 'Free,' which is not a behavioral trait. It does not state side effects, auth requirements, or what happens when called.
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 extremely short (one sentence), but it does not earn its place: it is vague and omits critical information. Conciseness should not come at the cost of completeness.
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?
Despite the tool's simplicity (single parameter, no output schema), the description fails to explain what a 'scoreboard' contains, how to interpret results, or any other context needed for correct 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?
The sole parameter 'filingId' has no description in the schema (0% coverage), and the tool description adds no meaning—it only mentions 'filing' generically. The agent gets no help understanding what value to provide.
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 it provides a 'Post-earnings scoreboard for a filing,' which indicates the resource (scoreboard) and action (retrieve/call), but it lacks specificity and does not distinguish from sibling tools like 'leaderboard' or 'ticker_consensus'.
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. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!