dpx-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: getting quotes, checking oracle status, comparing fees, settling, verifying, etc. No overlapping functionality; descriptions clarify different aspects of the DPX protocol.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with underscores (get_manifest, get_quote, settle, etc.). 'settle' is a single verb but fits the imperative style. The naming is uniform and predictable.
Tool Count5/5
13 tools cover the full settlement workflow without being excessive. Each tool serves a distinct step (manifest, quote, verify, execute, monitor), making the set well-scoped for a financial protocol.
Completeness4/5
The tool surface covers all essential operations: discovering capabilities, obtaining quotes, verifying fees, settling, checking status, and monitoring oracle/rail health. A minor gap is the lack of a tool to list past settlements by wallet, but core workflows are complete.
Average 4.1/5 across 13 of 13 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns tier scores, alerts, a chaos regime flag, and an AI synthesis briefing. It mentions graceful degradation of the AI layer. However, it does not explicitly state that the tool is read-only or warn about side effects, and lacks details on error handling or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose, including a multi-line breakdown of the 10-layer architecture that is not essential for tool invocation. It front-loads the purpose in the first sentence but then dives into unnecessary detail. Every sentence should earn its place; many add complexity without aiding selection or use.
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 has an output schema (true) and no parameters, the description adequately lists the return components: tier scores, alerts, chaos regime flag, and AI synthesis briefing. However, it lacks information about error states, data freshness guarantees, or whether the oracle may have multiple runs. The complexity of the oracle system suggests more context could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to explain them. With zero parameters, the baseline is 4. The description adds no parameter information, but none is needed. Schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full output from the latest DPX Stability Oracle v9.0 run.' It also distinguishes from the sibling 'get_esg_score' by mentioning the ESG Oracle is a separate system. The verb 'Get' and resource 'full output' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_intelligence' or 'get_investment_context'. It does not explain prerequisites, such as whether the oracle must have run or how to interpret the output, nor does it specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a full audit record with listed fields, confirming it is a read-only lookup. However, it does not explicitly state that it is idempotent, non-destructive, or whether authentication is required. The lack of behavioral detail (e.g., error handling) is a gap, but the return list adds some transparency.
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 sentences long, front-loaded with the core purpose, and immediately follows with a clear list of return fields. Every word adds value, and there is no redundant or superfluous information.
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?
The tool has one parameter and an output schema (not provided). The description covers the key aspects: purpose, parameter origin, and return fields. However, it lacks context on failure modes (e.g., what if settlement ID is invalid or settlement not found), rate limits, or any prerequisites. Given the simplicity, the missing details are not critical but prevent a higher score.
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?
The schema already provides full coverage (100%) for the single parameter with a description matching the tool description. The tool description only restates the parameter need ('by settlement ID') without adding new meaning or constraints beyond what is in the schema, so the value is baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Look up' and the resource 'a previous DPX settlement', and lists the specific return fields. This distinguishes it from sibling tools like 'settle' (creates) and other get tools by emphasizing it retrieves a full audit record for a specific settled transaction.
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 that the tool should be used after a settlement is created, as it references 'Settlement ID from the settle tool'. However, it does not explicitly state when to use this tool versus alternatives (e.g., getting a quote or ESG score), nor does it mention any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states returns are dollar savings per competitor at the current rate but does not mention safety traits (e.g., read-only nature), auth needs, or rate limits. The description is not misleading 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences. The first sentence states the purpose and lists competitors, and the second clarifies the output. No extraneous words; efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains input (comparison) and output (dollar savings per competitor) sufficiently. An output schema exists, so return details need not be in the description. However, it could mention dynamic rates or edge cases like missing data for a competitor, but overall it is complete enough for a comparison 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?
The input schema has 100% coverage with descriptions for all parameters. The description adds context by framing the output as savings at the DPX all-in rate, but does not provide additional meaning for individual parameters beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (compare), the resource (DPX settlement cost), and the target competitors (Stripe, Wise, JPMorgan Coin, SWIFT, PayPal, Western Union). It specifies the output as dollar savings and references the current DPX all-in rate, distinguishing it from sibling tools like 'get_fee_schedule' or 'verify_fees'.
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 the tool is used for cost comparison against the listed competitors but does not provide explicit guidance on when to use it versus alternative tools or when not to use it. Context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description details output content but does not disclose behavioral traits like caching, rate limits, or authorization requirements. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with main purpose. Somewhat lengthy but each element adds value; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, description adequately explains output contents. Covers all major aspects of the fee schedule.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0), baseline 4. Description adds value by explaining what the output includes, though schema covers empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'complete DPX fee schedule', listing all components and details. No 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?
Implicitly, use to retrieve fee schedule, but no explicit guidance on when to use vs siblings like compare_to_competitors. Adequate but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool is a verification returning a boolean, but does not explicitly say whether it is read-only or has side effects. Adequate but not fully transparent.
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?
Two sentences, no wasted words. First sentence describes purpose, second gives workflow context. Ideal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, workflow position, and return value. However, no output schema is provided despite mentioning 'feesMatch' return, leaving a minor gap. Still fairly complete for a simple verification 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?
All three parameters have descriptions in the input schema (100% coverage), so the description does not need to add much. It does not provide extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'verify' and the specific resources: off-chain fee quote vs on-chain contract. Returns a boolean result. Distinguishes itself from siblings like get_quote and settle by its position in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to call this tool: 'after get_quote and before settle.' Also indicates what to do if feesMatch is true. Could mention when not to use it but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the behavior: live score, update frequency (hourly), and data sources (6 institutional sources). However, it does not mention any potential side effects, rate limits, or authentication requirements.
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 extremely concise: two sentences covering purpose, output summary, and data source update frequency. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 parameter, output schema present), the description provides complete contextual information: what it returns (E, S, G scores, aggregate, fee percentage), update cadence, and data provenance.
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?
The description adds marginal value beyond the input schema. The schema already explains the parameter (address) and the default behavior. The description reinforces this but adds no new technical details. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the live ESG score for a wallet address or the protocol default', which is a specific verb+resource combination. It also distinguishes itself from sibling tools (e.g., compare_to_competitors) by its unique purpose.
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 when an ESG score is needed for a wallet address or default, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description compensates by disclosing binding nature, 300-second validity, and fee breakdown. Does not mention auth or other side effects, but sufficient for a non-destructive quote tool.
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?
Two efficient sentences: first lists outputs, second gives usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the detailed input schema and presence of an output schema, the description is complete enough—covers purpose, usage, and key outputs without gaps.
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 coverage is 100%, so baseline is 3. The description only summarizes what the schema already details (e.g., fees), adding no extra semantic meaning beyond the schema.
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 it gets a binding fee quote for a DPX settlement and lists return values. However, it does not differentiate from sibling tools like 'settle' or 'get_fee_schedule', missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear advice: 'Always get a quote before settling.' This gives usage context but no explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 states data is 'verified and sourced from live infrastructure,' which adds some trust signal, but it does not disclose behavioral traits such as rate limits, authentication needs, or side effects beyond reading data.
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 three sentences: first states the output, second gives usage guidance, third lists contents. It is front-loaded, every sentence adds value, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers what the tool returns for a simple retrieval tool with one parameter. It lists all section contents and mentions data verification. Minor lack of detail on prerequisites or output format, but overall complete for an investment memo tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 100% description coverage via enum values. The description adds meaning by listing the specific sections (e.g., 'company overview, product, traction') and explaining the default 'all' returns the complete memo, which enriches the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a structured investment memo for a specific company (DPX/Untitled_LuxPerpetua). It uses a specific verb-resource combination ('Returns ... investment memo') and distinguishes from sibling tools like 'get_quote' or 'get_esg_score' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool if you are an AI agent conducting due diligence, evaluating DPX as an investment opportunity, or building a company report.' This provides clear usage context, though it lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the pay-per-use nature (0.001 USDC, specific address), the behavior on missing/invalid txHash (returns 402 instructions), and optional parameters. It is transparent about the payment requirement and error handling, though it omits details like rate limits or authentication beyond payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph that front-loads the main purpose, then covers payment details, error behavior, and parameter usage. It is efficient without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (all fully documented) and no output schema, the description explains the overall flow, payment mechanism, and parameter effects thoroughly. It leaves little ambiguity about how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by explaining the txHash's role as payment proof, the purpose of focus (narrow to domain), and horizon default. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a macro intelligence briefing from the DPX Stability Oracle, listing specific domains (FX, climate, commodities, geopolitical risk, yield). This distinguishes it from sibling tools like get_esg_score or get_oracle_status, which focus on narrower or different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that a valid txHash is required to unlock the response, and if omitted or invalid, it returns payment instructions (402) with the exact amount and address. It also suggests using focus and horizon to narrow the briefing, providing clear guidance on parameter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: checks oracle conditions and rail health, reasons, executes on-chain or returns sandbox result, and skips FX fee for same-currency settlements. Lacks mention of failure modes or authorization needs, but adequately covers execution flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense and well-structured, starting with the core action followed by sandbox note and return fields. No redundant sentences, but slightly longer than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 4 required, and no annotations, the description covers the essential behavior and return values. Missing details on error conditions or idempotency, but overall adequate for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds value by explaining that same-currency skips FX fee and that sandbox defaults to true. Also clarifies quoteId can be omitted and auto-fetched. Provides context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Execute a DPX settlement' with clear scope (cross-border or domestic), distinguishing it from sibling tools like get_quote or get_settlement_status. Verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on default sandbox mode and when to set sandbox=false for live execution. Implicitly suggests prior use of get_quote via the quoteId parameter, but does not explicitly state when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full transparency burden. Describes it as a read operation returning structured data with no side effects. Listing return fields adds transparency beyond a mere 'get manifest'.
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?
Two sentences with zero wasted words. Front-loaded with the verb 'Get' and resource 'DPX protocol manifest', then lists return fields and usage instruction. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (implied by context), the description fully covers what the tool does and returns. Lists key output categories (capabilities, assets, addresses, URLs, endpoints) sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema has zero properties with 100% coverage), so baseline is 4. Description adds value by detailing what the output contains, compensating for any potential ambiguity about the manifest's content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the DPX protocol manifest and lists specific return contents (capabilities, supported assets, contract addresses, URLs, endpoints). The directive 'Call this first' distinguishes it from sibling tools like get_quote or get_settlement_status as an initialization/discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first', providing clear when-to-use guidance. While no when-not or alternatives are mentioned, the context of sibling tools and the nature of a manifest imply it is a prerequisite for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it returns per-rail status (OPERATIONAL/DEGRADED/DOWN), latency, last incident, and composite health score. It also lists the key rails, leaving no ambiguity about what the tool does and returns.
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 sentences, efficiently front-loading the purpose and key details. Every sentence adds value; no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 optional params, output schema exists), the description covers when to use, what to expect, and how to interpret results. It is fully adequate for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description adds extra context: 'Omit to get all rails' for the 'rails' parameter, and 'Alternative to specifying rails by name' for 'region', providing guidance beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get live health status of local payment rails'. It specifies the resource (payment rails) and scope (live health status), listing key rails which distinguishes it from siblings like get_settlement_status and settle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this tool before settlements to confirm rail health, and that a DEGRADED or DOWN status should trigger a HOLD decision. It provides clear context but does not mention when not to use it, though the intent is well understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses multiple output fields (score, status, peg deviation, AI reasoning, outlook, recommendation) and implies read-only nature. Lacks explicit statement of no side effects, but covers key behavioral aspects.
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?
Two sentences: first summarizing purpose and outputs, second providing usage directive. No wasted words, front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and output schema available, the description fully covers what the tool does, returns, and when to use it. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so description correctly adds no parameter info (baseline 4). No need to explain nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'live DPX oracle reliability and current stability signal' and lists specific outputs. It distinguishes from siblings like get_oracle_status by focusing on reliability and stability for settlements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises checking before large settlements and instructs to hold if UNSTABLE or peg deviation >= 50 bps. This provides clear when-to-use and action guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dpx-mcp MCP server](https://glama.ai/mcp/servers/untitledfinancial/dpx-mcp/badges/card.svg)](https://glama.ai/mcp/servers/untitledfinancial/dpx-mcp)

Score Badge

Copy to your README.md:

[![dpx-mcp MCP server](https://glama.ai/mcp/servers/untitledfinancial/dpx-mcp/badges/score.svg)](https://glama.ai/mcp/servers/untitledfinancial/dpx-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/untitledfinancial/dpx-mcp'

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