Marqeta DiVA API MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct data type or aggregation level (authorizations, settlements, declines, balances, counts, etc.) with clear descriptions. Even related tools like get_chargebacks_detail and get_chargebacks_status serve clearly different purposes (detail vs status). No overlapping ambiguity.
Naming Consistency4/5
Most tools follow a 'get_' prefix with a noun describing the data (e.g., get_authorizations). Two exceptions: export_view_to_file and list_available_views use different verbs, but these are distinct actions (export vs list) and still clear. Overall pattern is consistent and readable.
Tool Count5/5
20 tools is well-scoped for a financial reporting API. Each tool corresponds to a specific endpoint or metric, and the count covers the full range of DiVA views without unnecessary duplication. It's not too heavy nor too thin.
Completeness4/5
The tool set covers the major reporting areas: authorizations, settlements, declines, chargebacks, balances, cards, users, counts, and export. Minor gaps exist (e.g., no refunds or dispute tools), but for a typical reporting use case, the coverage is thorough and no critical dead ends are apparent.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on November 17, 2025
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It states it retrieves data but does not mention read-only nature, authorization needs, rate limits, or any side effects. The description only hints at the content, not behavior.
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?
Two sentences, no fluff. Front-loaded with the core action. Could be slightly more structured, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations. The description does not explain return values, pagination (despite a count parameter), or how to interpret the comprehensive details. Lacks sufficient context for an agent to fully understand the tool's behavior.
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?
Input schema has 100% parameter description coverage, so the description does not need to add much. However, the description adds no context about the parameters beyond what the schema provides, which is adequate but not enriching.
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 indicates it retrieves detailed chargeback information, including transaction dates/types. It distinguishes from the sibling 'get_chargebacks_status' by implying greater depth, but could be more specific about what 'comprehensive' entails.
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?
No guidance on when to use this tool versus alternatives like 'get_chargebacks_status'. No mention of prerequisites or context.
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?
Discloses the 10,000 record API limit, which is helpful. Lacks details on read-only nature, authentication needs, or side effects. With no annotations, the description carries the burden but only partially covers behavioral context.
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?
Two concise sentences, front-loaded with purpose. The second sentence adds valuable information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description only vaguely mentions 'load amounts and transaction details'. For a tool with 6 parameters and nested objects, this is insufficient. Agent cannot infer what data is returned or how filters apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds little beyond schema; the limit warning is tangentially related to the 'count' parameter but does not enhance understanding of each parameter's meaning.
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?
Description states 'Get load transaction data' which is a specific verb and resource. However, it does not distinguish from sibling tools like get_activity_balances or get_authorizations.
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?
No guidance on when to use this tool vs alternatives. Only mentions API limits and suggests narrower filters, but no context on when not to use or which sibling is appropriate.
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 carries full transparency burden. It states the data included (state, tokens, provisional credit) but omits behavioral details like default record limits (implied by count parameter), pagination, or authentication requirements. Adequate but not thorough.
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 a single sentence with no redundant words, earning every part. It efficiently conveys purpose and key output elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, yet the description only names three output fields. It does not explain how parameters like filters, sort_by, or program affect results, leaving the agent with incomplete context for effective invocation.
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 3. The description adds no additional parameter meaning beyond the schema. It mentions output fields but not parameter-specific usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves chargeback status data and specifies three components included. However, it does not differentiate from the sibling tool 'get_chargebacks_detail', which may lead to confusion about which tool to use for detailed vs. summary data.
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?
No guidance is provided on when to use this tool over alternatives like 'get_chargebacks_detail' or other status tools. The description lacks context for appropriate selection among siblings.
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 carries the burden. It discloses the 10,000 record limit from the DiVA API, which is a key behavioral constraint. However, it does not mention read-only nature, authentication, or side effects. It adds some value but leaves gaps.
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 brief yet informative: 4 sentences front-loaded with purpose and metrics. No redundancy or filler. Every sentence adds value, making it highly concise and well-structured.
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?
Covers aggregation options and record limits, but lacks output representation details (no output schema). Does not explain how filters or other parameters affect results. Adequate for basic use but incomplete for complex queries.
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 adds context by naming specific metrics (accounts, suspended, growth) not in the schema, and the API limit note relates to the count parameter. But it does not explain parameter details beyond what the schema provides.
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 retrieves aggregated user count metrics over time, specifying metrics like accounts, suspended users, and growth. It is specific and actionable, but does not differentiate from sibling tools like get_card_counts or get_users, so not a 5.
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?
No guidance on when to use this tool versus alternatives. It says 'Essential for program monitoring and analytics' but lacks explicit when-to-use, when-not-to-use, or sibling comparisons. The description implies usage for aggregate trends but does not exclude other scenarios.
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?
Without annotations, the description carries the full burden of disclosing behavior. It does state that only day-level aggregation is supported, which is a useful constraint. However, it omits other behavioral traits such as authorization requirements, rate limits, data freshness, or what happens when no data matches.
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 at two sentences, with no extraneous information. Every word serves a purpose, and the most important information (cardholder-level, day aggregation, expandability) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand the tool. It does not explain the meaning of 'cardholder-level', the available fields, date filtering behavior, or how network expansion works, leaving significant 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?
Input schema coverage is 100%, so each parameter already has a description. The tool description adds only a mention that data is 'expandable by network', which aligns with the 'expand' parameter described in the schema. The description provides no additional semantic value 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?
The description clearly states the tool retrieves cardholder-level balance data, specifies it includes individual balances and is expandable by network, and notes day-level aggregation only. This provides a specific verb and resource, and implicitly distinguishes from program-level balance tools like get_program_balances.
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?
No guidance is provided on when to use this tool versus siblings such as get_activity_balances_network_detail or get_program_balances. The description does not mention prerequisites, alternatives, or scenarios where this tool is preferred.
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?
The description discloses a key behavioral constraint: 'DiVA API limits results to 10,000 records per query.' However, it does not mention read-only status, required permissions, or side effects. With no annotations, the description carries the full burden but only partially covers behavioral traits.
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 three sentences long, with the first sentence stating the primary purpose. It efficiently conveys key points without unnecessary detail, making it easy to scan.
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 6 parameters, nested objects, and no output schema, the description provides essential context (aggregation types, API limit) but lacks details about return format or pagination behavior. It is adequate but not fully complete.
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?
Input schema covers all 6 parameters with 100% description coverage, so the schema does the heavy lifting. The description adds some context (example metrics like 'active cards, suspended cards'), but does not elaborate on parameter details beyond what the schema provides.
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 retrieves aggregated card count metrics over time, specifying example metrics like cards in circulation. It distinguishes itself from sibling 'get_cards' by focusing on aggregated counts rather than individual card records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for program health monitoring ('Essential for program health monitoring'), but does not provide explicit guidance on when to use this tool vs alternatives like 'get_cards' or 'get_user_counts'. No when-not or comparison is given.
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 must fully disclose behavior. It mentions the API record limit, which is useful. But it lacks information on read-only status, authentication needs, rate limits, or error handling, leaving gaps in 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-loading the primary purpose and immediately following with a critical usage note. No extraneous information is present.
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 6 parameters, nested objects, and no output schema, the description covers basic purpose and a key limitation but omits details on return format, aggregation behavior nuances, and more comprehensive filter examples. It is minimally adequate.
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?
Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value with a filter example and the 10,000-record limit context, but does not significantly enhance understanding of each parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('settlement transaction data'), and lists included fields. However, it does not explicitly differentiate from sibling tools like get_authorizations or get_clearings, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a contextual note about the 10,000-record limit and suggests using narrower date ranges or filters for larger datasets. However, it does not offer explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions.
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 alone must disclose behavior. It correctly implies a read-only operation and mentions the API limit, but does not detail other traits like performance, caching, or data freshness. No contradictions.
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 two short sentences that convey purpose, contents, and a key limitation. No 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?
Without an output schema, the description partially addresses return values by listing some fields. However, it does not fully describe the output structure or pagination behavior. Adequate but not comprehensive.
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% description coverage, so the description's mention of specific fields adds marginal value. It does not elaborate on parameter usage beyond what the schema already provides.
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 'Get card detail data' and lists included fields (user tokens, card state, etc.). It is specific but does not explicitly differentiate from siblings like get_card_counts or get_users, though the purpose is distinct.
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 advises on filtering and notes the 10,000 record limit, suggesting use of narrower date ranges or more specific filters. This provides clear usage guidance, though it doesn't mention when not to use this tool or direct to 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?
No annotations are provided, so the description bears full burden. It discloses that data includes settlement balance info and fund transfers and is day-level aggregated. However, it does not mention return format, pagination, or side effects (e.g., read-only nature), which leaves gaps for a tool with no output schema.
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, direct, and front-loaded. Every sentence contributes purpose (what, includes, granularity). No extraneous text.
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 no output schema, the description should explain return values. It mentions inclusions (settlement balance info, fund transfers) and granularity but lacks details on return structure or default behavior (e.g., program override). The five parameters are covered in schema, so additional context on outputs is missing.
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 parameters are described in the input schema (100% coverage), so the description adds minimal extra meaning. The mention of 'Day-level aggregation only' indirectly informs date filtering but does not elaborate on parameter usage or required formats 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?
The description clearly states the tool gets settlement-based program balance data, specifying it includes settlement balance information and fund transfers, and notes day-level aggregation. This distinguishes it from siblings like get_activity_balances or get_program_balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for daily aggregated settlement data with 'Day-level aggregation only' but does not explicitly state when to use this tool versus alternatives or when not to use it. No comparison to sibling tools is provided.
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 must carry the behavioral burden. It states the return type (field names, data types, descriptions) but does not disclose potential errors, authentication needs, or rate limits. This is minimally adequate for a read-only schema endpoint.
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 concise sentences with no extraneous information. The first sentence states the purpose, the second specifies return content. Every word earns its place.
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 description is brief but adequate for a simple schema retrieval tool. It lacks details on output format or constraints, but the tool's function is clear given the name and sibling context. Without output schema or annotations, more detail could improve completeness.
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 both parameters (view_name and aggregation). The description adds little beyond the schema, merely referencing 'any view endpoint'. Baseline score of 3 is appropriate given full schema documentation.
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 'Get', the resource 'schema definition for any view endpoint', and specifies output ('field names, data types, and descriptions'). It effectively distinguishes from sibling data retrieval tools like get_authorizations or get_cards.
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 does not explicitly state when to use this tool versus alternatives. It implies usage for schema exploration, but lacks guidance on when not to use it or mention of alternative tools. Given the numerous sibling tools, more explicit context would be helpful.
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 must disclose behavioral traits. It mentions day-level aggregation, which is a key behavioral constraint, but does not explicitly state that the tool is read-only, nor does it discuss authentication, rate limits, or potential side effects. The description provides some transparency but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose, and contains no extraneous words. Every sentence contributes meaningful information.
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 absence of an output schema, the description adequately explains the returned data (balance details, day-level aggregation). It covers the essential behavioral aspect (aggregation) but could mention pagination or default count (10,000) as context. Still, it is largely complete for a simple listing 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 five parameters have descriptions in the input schema (100% coverage). The tool description does not add parameter-level details beyond what the schema provides, so the baseline of 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 the tool retrieves program-level balance data, specifies the included fields (beginning/ending bank balances, amounts to send/receive), and notes the day-level aggregation. This distinguishes it from sibling tools like get_activity_balances (likely transaction-level) and get_program_balances_settlement (settlement-level).
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 explains what the tool does but provides no guidance on when to use it versus alternatives like get_activity_balances or get_program_balances_settlement. Usage context is implied but not explicit.
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 carries full burden. It describes the data returned and the limit, implying a read-only operation, but lacks details on authentication, side effects, or consistent behavior across parameters.
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: the first states the core purpose concisely, the second adds a critical limitation. No superfluous words, 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?
Given the number of parameters and siblings, the description covers the main functionality, includes included data, and warns about the limit. It could mention the output format or program override, but schema covers parameters.
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 each parameter is already documented. The description adds context about the returned data but does not enhance understanding of the parameters themselves beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'user detail data' with specifics about included fields (tokens, UAI, card counts). The phrase 'Detail-level only' hints at differentiation from summary tools, but no explicit sibling comparison.
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 note about the 10,000 record limit and suggestion to use specific filters for larger datasets provides concrete usage advice. However, it does not specify when to use alternatives among siblings like get_user_counts.
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 full burden. It discloses 'Day aggregation only' and includes PIN and signature purchases. It explains the 'expand' parameter behavior. However, it does not mention limitations like the 10,000 record cap, potential authorization requirements, or side effects. Missing some important behavioral context.
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 3 sentences, each earning its place: purpose in first sentence, relevant details (day aggregation, expand usage) in the second, and a concluding statement on value. No filler or redundant 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?
Given the complexity (6 parameters, nested objects, no output schema), the description covers core purpose and the expand parameter but lacks details on how to use filters effectively, pagination, or the structure of the response. Adequate but with gaps that could confuse an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the 'expand' parameter further, but does not enhance other parameters like 'fields', 'filters', or 'sort_by' beyond the schema descriptions. Overall, marginal added meaning.
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 specifies the verb 'Get', the resource 'activity balance data', and the key attribute 'broken out by card network'. It lists example networks and mentions PIN and signature purchases, clearly distinguishing it from sibling tools like 'get_activity_balances' that likely provide aggregate data without network breakdown.
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 implies usage for network-specific transaction volumes and instructs to use the 'expand' parameter for specific transaction types. However, it does not explicitly state when not to use this tool or mention alternative tools for other types of balance analysis, which would strengthen guidance.
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 the full burden. It indicates a lookup/mapping operation (likely read-only) but does not disclose side effects, authentication requirements, or rate limits. The behavioral intent is clear 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?
Three sentences: definition, importance, usage directive. Every sentence adds value with no redundancy. Front-loaded with the key action verb and resource.
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 description covers purpose and usage well but omits return value structure, pagination, or error handling. Given no output schema, more context about the response format would improve completeness. However, the core context for the mapping task is present.
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 the description does not add meaning beyond schema descriptions. The description reinforces the mapping purpose but does not elaborate on parameter usage or constraints. 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 uses a specific verb ('Map') and resource ('Core API transaction tokens to DiVA report transaction tokens'), clearly differentiating it from sibling tools like get_authorizations or get_loads. It states its critical role in reconciliation workflows.
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 states the tool is for reconciling transactions between Core API and DiVA reporting, giving clear context. However, it does not mention when not to use it or suggest alternative tools, though none seem obvious among siblings.
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 the full burden. It minimally discloses behavior (listing view endpoints with metadata) but does not mention read-only nature, idempotency, or rate limits. Given the tool's simplicity, this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both essential and without superfluous words. It is front-loaded with the key action and purpose.
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 no output schema and no annotations, the description is minimal. It states what it does but does not describe the return structure or what metadata is included. For a simple list endpoint, it is adequate but lacks detail that would help an agent interpret results.
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 tool has no parameters, so the description adds no parameter information. Per guidelines, zero parameters yields a baseline score of 4. The description does not need to elaborate further.
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 action 'Get a list of all available DiVA API view endpoints with metadata' and the purpose 'discovering available data sources'. It distinguishes the tool from sibling tools that retrieve specific data (e.g., get_cards, get_balances) by focusing on listing available views.
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 implies usage for discovery before using other view-specific endpoints, but does not explicitly state when to use vs alternatives or when not to use. For a simple enumeration tool, the context is clear enough.
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 are provided, so the description bears the full burden. It discloses the API limit and suggests workarounds, providing important behavioral context. It could be more explicit about file overwriting, but the given information is adequate.
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 concise sentences, front-loaded with the purpose, followed by a crucial behavioral note. No unnecessary words.
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's complexity (9 parameters), no output schema, and no annotations, the description covers the essential purpose, limit, and support for view types. Could mention output file handling, but overall sufficient.
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?
Input schema has 100% description coverage, so the baseline is 3. The description adds minor value by emphasizing the limit, but the schema already explains parameters well.
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 action (Export datasets) and the resource (to a file in JSON or CSV). It lists supported view types, distinguishing it from sibling 'get_' tools that retrieve data without writing to files.
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 notes the DiVA API limit of 10,000 records and advises using narrower filters or multiple calls for more data. It implies when to use this tool (for exporting to file) without specifying explicit when-not-to-use scenarios, but the context of sibling tools makes it 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?
No annotations are provided, so the description carries full responsibility. It discloses the DiVA API limit of 10,000 records per query, which is a critical behavioral trait. It also implies read-only behavior (get). However, it does not describe the response format or potential error states, but the limit disclosure is substantial.
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, each serving a distinct purpose: the first explains the tool's functionality and aggregation levels, the second warns about the API limit. No wasted words, and the key information is front-loaded. Ideal conciseness.
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 output schema and complex input parameters, the description covers the core functionality, aggregation options, and a crucial performance limitation. It could mention default time ranges or prerequisite permissions, but for a data retrieval tool, the provided information is mostly sufficient. The lack of output schema details is acceptable since the tool is a standard get query.
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 the baseline is 3. The description adds value by providing an example of filter syntax (e.g., {'transaction_timestamp': '>=2023-10-20'}) and explicitly warns against including query parameters like 'count' or 'sort_by' in the filters. This extra guidance improves parameter understanding 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?
The description clearly states the tool retrieves authorization transaction data with specific elements (amounts, counts, users, cards, merchants) and supports multiple aggregation levels. This verb+resource clarity distinguishes it from sibling tools like get_cards or get_chargebacks_detail.
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 mentions the API limit of 10,000 records and suggests using narrower date ranges or filters for larger datasets, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use get_authorizations vs. get_declines or other transaction tools). Context is given for handling pagination limits, but comparative usage is missing.
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 burden. Discloses the 10,000-record API limit and notes aggregation options. Does not cover rate limits or data freshness, but the limit disclosure is a valuable behavioral trait.
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?
Four concise sentences, front-loaded with purpose. Every sentence adds value: purpose, use case, aggregation support, and API limit advice. No fluff.
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?
Covers purpose, aggregation, and a critical constraint (10k limit). Lacks explanation of return values (no output schema) and pagination, but given the complexity of clearing data, this is adequate for initial selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description adds limited value. It reiterates aggregation enum values and the count limit, but these are already in the schema. No additional meaning 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?
Clearly states the tool retrieves clearing/reconciliation data with accounting-level line items, ideal for reconciliation. This distinguishes it from siblings like get_settlements or get_authorizations.
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 recommends usage for reconciliation and advises on API limits (10,000 records) with concrete suggestions for larger datasets. Missing explicit when-not or sibling comparisons, but context from sibling list helps.
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 describes a read operation without mentioning safety or authorization requirements. However, for a simple version check, the risk is low. It doesn't disclose whether the call is read-only or if it has side effects, but the context implies it's safe.
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 a single, focused sentence with no wasted words. It conveys the action, resource, and purpose efficiently.
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, no output schema, and a simple purpose, the description is nearly complete. It explains why to use it. A minor gap is not describing the return value format (e.g., version string), but the purpose implies what the output represents.
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 zero parameters with 100% coverage. The description adds no parameter information, which is acceptable since there are none. Per guidelines, zero parameters baseline is 4.
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 action ('Get') and the resource ('MCP server version'), along with a specific purpose ('to verify it has been restarted with latest code changes'). This is unambiguous and distinguishes it from sibling tools, which are data retrieval or export tools.
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 states when to use the tool: to verify the server has been restarted with latest code. While it doesn't mention when not to use it or provide alternatives, the simple nature of the tool makes these less critical. It gives clear context for appropriate use.
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, the description carries the full burden. It discloses the API limit and suggests mitigation strategies. The tool name 'get' implies read-only, but the description could explicitly state it is non-destructive. However, it sufficiently informs the agent of constraints.
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 plus a critical note. It front-loads the main purpose and efficiency provides necessary caveats without extraneous information.
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, aggregation types, filter guidance, and the limit. It lacks details about default fields or return format, but the schema handles parameter descriptions. Given no output schema and 6 parameters, it is nearly complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description provides additional meaning: it explains the aggregation parameter's supported levels ('detail, day, week, month'), gives a concrete example for filter usage with date operators, and implicitly covers the count parameter via the limit note.
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 declined transaction data, specifying included fields (transaction tokens, decline reasons, merchant information, amounts). The verb 'Get' matches the resource 'declines', and it is distinct from siblings that retrieve other transaction types or 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 provides explicit guidance on the 10,000-record limit and recommends using narrower date ranges or more specific filters for larger datasets. While it does not explicitly mention when not to use or suggest alternative tools, the context of siblings implies this is the specific tool for declines.
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:

[![marqeta-diva-mcp MCP server](https://glama.ai/mcp/servers/tbadlov/marqeta-diva-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tbadlov/marqeta-diva-mcp)

Score Badge

Copy to your README.md:

[![marqeta-diva-mcp MCP server](https://glama.ai/mcp/servers/tbadlov/marqeta-diva-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tbadlov/marqeta-diva-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/tbadlov/marqeta-diva-mcp'

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