First Dollar

Server Quality Checklist

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

Latest release: v1.0.7
Disambiguation4/5
Most tools have distinct purposes: lessons explain concepts, while practical tools like read-this-challenge, how-do-i-pay, and verify-my-purchase handle specific actions. A few educational tools (e.g., what-is-x402 vs. read-this-challenge) could be confused, but descriptions clarify the difference.
Naming Consistency4/5
Tool names are uniformly lowercase with hyphens, and most use an imperative verb or a 'what-is' pattern. The mix of verb phrases (get-a-wallet, verify-my-purchase) and noun phrases (what-is-usdc, what-is-acp) is slight but consistent enough to be predictable.
Tool Count4/5
At 19 tools, the set is on the heavier side but appropriate for a curriculum covering 16 lessons plus practical helpers. Each tool represents a distinct lesson or action, so the count feels justified rather than bloated.
Completeness4/5
The tool surface covers the full learning path from wallet basics to advanced protocols like AP2 and ACP, plus practical utilities for decoding challenges, paying, verifying, and troubleshooting. Minor gaps like missing explicit lessons 3, 8, 9, and 10 are likely covered by the practical tools, so no dead ends.
Average 4.2/5 across 19 of 19 tools scored. Lowest: 3.6/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
- 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.
This repository includes a glama.json configuration file.
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?
With no annotations, the description carries the burden of disclosing behavior. It clearly indicates this is an educational lesson rather than a system action, which is helpful. However, it does not describe what the agent/user will see (e.g., text, steps), or whether it tracks progress. Acceptable but not rich.
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 very concise: two sentences that clearly state the lesson number, topic, and purpose. Every word earns its place, with no fluff or repetition.
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?
For a simple lesson tool with no parameters and no output schema, the description is nearly complete. It names the lesson and the specific topic. However, it lacks explicit context about where this fits in the curriculum (beyond 'Lesson 16') or when an agent should invoke it relative to siblings.
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 zero parameters, and the schema coverage is 100% (vacuously). No parameter details are needed, and the baseline for 0-param tools is 4. The description appropriately focuses on content rather than inputs.
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 states it is a lesson about the four wallet-holding modes and how to choose among them. The resource is specific (wallet modes), and the verb is implied as 'teach/explain' via 'Lesson 16'. It is fairly clear and distinct from siblings, though it lacks an explicit action verb.
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 phrase 'how to pick' implies this tool is for deciding between wallet modes, providing some usage context. However, it does not explicitly contrast with alternatives like get-a-wallet or configure-wallet-skills, nor does it mention when not to use it. Guidance 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?
No annotations are provided, so the description carries the burden. It clearly indicates this is an educational lesson, implying no side effects. However, it does not explicitly state it is read-only or that it returns informational content, but the nature of the tool is evident from the name and description.
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 that front-loads the curriculum position ('Lesson 2') and concisely lists the three content areas. No wasted 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?
For a simple informational lesson with no parameters and no output schema, the description adequately covers the content. It does not mention prerequisites or next steps, but the curriculum context and sibling tool names partially fill that gap.
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 zero parameters, so the schema is trivially complete. The description correctly does not attempt to add parameter semantics. Baseline for zero parameters is 4.
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 identifies the tool as 'Lesson 2 of the curriculum' and specifies the topic: what USDC is, why it's the default currency for agent payments, and the importance of blockchain choice. This distinguishes it from siblings like 'what-is-x402' and 'what-is-a-wallet'.
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 use as part of a curriculum sequence ('Lesson 2'), but does not explicitly state when to use this tool over alternatives or provide exclusions. There is no guidance on prerequisites or progression, though the curriculum context gives some hint.
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 burden of explaining behavior. It states the lesson's content (what the merchant knows, public chain visibility, pseudonymity, hygiene rules) but does not describe how the lesson behaves (e.g., interactive, text-based, any side effects). Since it is a lesson, the behavior is implied but not explicitly disclosed.
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 that are front-loaded with the 'Lesson 12' identifier, followed by a clear summary of topics. Every word contributes to the meaning, with no filler or redundancy.
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?
For a lesson with no output schema or annotations, the description provides a thorough overview of the content and its place in the curriculum. It could be slightly more complete by mentioning delivery format or prerequisites, but the given information is sufficient for an agent to decide if this lesson is relevant.
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 zero parameters, so the baseline is 4. The description adds contextual meaning about the lesson topic, which is sufficient. No further parameter documentation is needed.
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 identifies the tool as 'Lesson 12' and specifies its scope: merchant knowledge, public chain revelations, wallet identity, pseudonymity, and hygiene rules. This distinguishes it from sibling lessons by topic. However, it lacks a direct verb like 'teaches' or 'explains', making it slightly less action-oriented.
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 'Lesson 12 of the curriculum' context implies a structured sequence, and the topic description suggests when it would be relevant (e.g., learning about wallet privacy). However, there is no explicit guidance on when to use this tool versus alternatives, no prerequisites stated, and no exclusions listed.
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 burden of explaining behavior. It states the lesson number and outlines exactly what topics will be covered, which tells the user what to expect. It doesn't discuss side effects or prerequisites, but as a lesson tool, this is sufficient.
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, front-loaded with 'Lesson 6 of the curriculum,' and uses concise language to list coverage areas. Every word earns its place without redundancy.
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?
For a simple informational lesson with no output schema and no annotations, the description gives enough context about the lesson's content and position in the curriculum. It could mention prerequisites or how the lesson is delivered, but this is not necessary for basic comprehension.
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 schema has zero parameters, and the baseline for 0 params is 4. The description adds no parameter-specific details, but none are needed since there are no parameters to describe.
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 identifies the tool as a curriculum lesson about getting USDC into a wallet, listing three specific coverage areas. It is distinct from sibling tools (e.g., what-is-a-wallet, get-a-wallet) by focusing on the funding process, though it doesn't explicitly name alternatives.
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 context implies usage when a user needs to learn how to fund their wallet, but there is no explicit 'use this when' or guidance on when to choose it over sibling lessons. Alternatives are not mentioned, leaving the decision to the user.
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 burden. It transparently states that it returns 'checks you can run yourself' rather than performing the checks, which clarifies its non-destructive, advisory nature. It also explains that it takes optional hints, setting expectations for input behavior. However, it does not explicitly state whether it scans the environment automatically or relies solely on hints.
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, directly front-loaded with the primary purpose. Every phrase adds value: the scope, the output, and the optional input. There is no unnecessary detail or repetition.
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?
For a simple tool with two optional parameters and no output schema, the description adequately explains what it does and what it returns. It covers the input hints and the type of output (checks to run and their meaning). The only minor gap is the lack of clarification on the default behavior when no hints are provided, but this is not critical for tool selection and 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?
The input schema already provides 100% coverage of the two optional parameters with descriptions. The description only adds a general reference to 'hints about your setup', which does not meaningfully expand on the schema's parameter descriptions. Therefore, baseline score 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 uses a specific verb ('Explains') and clearly identifies the resource (the user's wallets in their current environment) and the scope (chains and capabilities). It also distinguishes itself from sibling tools like 'what-is-a-wallet' by focusing on the user's specific environment rather than generic wallet concepts.
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 ('Explains what wallet(s) you have access to') but does not explicitly state when to use this tool versus alternatives like 'what-is-a-wallet' or 'get-a-wallet'. It does mention that hints are optional, which gives some input guidance, but lacks clear exclusions 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.
Behavior3/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 conveys that this is a lesson about scope-discipline rules, suggesting an informational, read-only behavior, but it never explicitly states the return format, side effects, or prerequisites. For a no-parameter content tool this is minimally adequate but not rich.
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 only two sentences, with the first sentence identifying the resource and the second summarizing the lesson's substance. Every clause adds value and the key phrase 'Lesson 15' is 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 tool's low complexity (no parameters, no output schema), the description supplies enough topical context and boundaries to decide whether to use it. It could be slightly stronger by stating the expected outcome of invoking the lesson, but the current content is sufficient for selection.
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 is empty with zero parameters, and schema description coverage is 100%. The rubric baseline for zero parameters is 4, and the description correctly avoids inventing parameter details; no additional parameter semantics are possible or necessary.
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 explicitly identifies the tool as 'Lesson 15 of the curriculum' and pinpoints the exact topic: ERC-7715 scoped autonomy, with concrete learning points ('approve once, spend within bounds', 'when to ask, when to refuse'). This clearly differentiates it from sibling tools such as 'what-is-x402' or 'how-do-i-pay' by naming a unique lesson and subject.
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 phrase 'Lesson 15 of the curriculum' implies sequential use within the curriculum, but it does not explicitly state when to choose this tool over alternatives or when not to use it. No exclusions or alternative tool references are provided, so usage is implied rather than explicit.
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 the burden and does well by explicitly stating 'First Dollar does not sign for you — it shows you what to run.' This prevents the false expectation that the tool executes the payment. It does not address errors or permissions, but for a simple instructional tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences with no filler. The first sentence front-loads the main purpose, and the second adds a valuable disambiguation. Every sentence earns its place.
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?
For a tool with one parameter, no output schema, and no annotations, this description covers the core outcome, input condition, and a key limitation. It does not specify the exact format of the returned commands or prerequisite wallet setup, but the sibling tool names and schema hint at the broader context, making it sufficiently complete for an 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?
The schema already provides full coverage for the single parameter ('The raw 402 response or PAYMENT-REQUIRED header value'), so the baseline is 3. The description does not add parameter-level syntax or format guidance; its phrase 'decoded x402 challenge' actually introduces a slight conflict with the schema's 'raw' qualifier, so no extra credit is warranted.
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 uses a specific verb ('returns') and states the exact deliverable: 'specific signing steps and wallet-specific commands you can run to produce a valid payment.' It also distinguishes itself from sibling tools by noting 'First Dollar does not sign for you,' making it clear this is instructional, not an execution 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?
The description gives a clear precondition ('Given a decoded x402 challenge') and implies the user should call it when they need commands to produce a payment. It does not explicitly name alternatives or exclusions, but the context is sufficient for selection among siblings.
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 must convey behavior and does so by outlining the lesson's educational content: why HTTP 200 doesn't guarantee delivery, documented attack classes, and a practical verification flow. It does not disclose whether the tool is purely informational or requires any actions, but for a curriculum lesson this content overview is reasonable.
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 only two sentences, front-loaded with the curriculum identifier, and every clause adds meaningful detail about the lesson's focus. No redundant or filler content.
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?
For a simple content-delivery tool with no parameters or output schema, the description covers the main educational points adequately. It could mention expected audience or relationship to adjacent lessons, but the sibling list and the 'Lesson 11' context supply that context.
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 zero parameters, so the schema vouches for everything. The description adds no parameter details, but none are needed. Baseline of 4 applies for parameterless tools.
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 this is 'Lesson 11 of the curriculum' and specifies the unique topic: the distinction between HTTP 200 and actual delivery, five attack classes against x402, and a verification flow. It distinguishes itself from sibling lessons like 'what-is-x402' and 'verify-my-purchase' by focusing on the buyer-side verification context.
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 phrase 'Lesson 11 of the curriculum' implies sequential usage—the learner should proceed in order—but there is no explicit guidance on when to use this over alternatives, nor any mention of prerequisites or exclusions. The intended usage is inferable rather than 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 are provided, so the description carries the full burden. It discloses that the tool verifies 'wallet + signing + settlement end-to-end' and mentions free versus paid products, but does not explain side effects like whether real transactions are initiated or whether a funded wallet is required.
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 no wasted words. The first sentence states the purpose, and the second gives concrete starting points. Each phrase earns its place.
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?
For a tool with one optional parameter and no output schema, the description covers the main use case, the default, and the alternative. It could note prerequisites like needing a configured wallet, but sibling tools (configure-wallet-skills) handle that, so the description is sufficiently complete.
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 schema already documents the single parameter fully (100% coverage) with a default. The description adds value by explaining what the default offers ('free products for handshake, $0.99 paid products for settlement') and letting users supply their own URL, which clarifies the practical use of the parameter.
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 'Walks you through' and names the resource 'test-payment handshake against any x402 merchant'. It clearly distinguishes from sibling tools, which are predominantly explanatory, by being an interactive verification action.
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?
It gives explicit guidance on where to start: 'Suggested first stop: the Underground Cultural District' and offers an alternative 'Or supply your own merchant URL.' This provides clear context for when to use the tool, though it does not explicitly state 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.
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 that the tool is instructional/read-only (it 'explains' and 'Returns the command'), and it clarifies the scope (does not process payment itself, just generates a command). It doesn't describe side effects, but given the non-mutating nature implied, this is adequate though it could state explicitly 'does not execute the command'.
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, front-loaded with the when-to-use clause and efficiently conveys purpose and output. No wasted words; it earns every phrase.
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?
For a tool with 3 simple params, no output schema, and no annotations, the description is fairly complete: it states the workflow position, the exact output (command + explanation), and the endpoint involved. It could be slightly more specific about the command's nature (e.g., HTTP) and response format, but the essentials are covered.
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 no direct parameter-specific details beyond the schema, but it does contextualize the parameters (e.g., 'transaction hash' relates to tx_hash, 'merchant's /receipt endpoint' to merchant_url). The schema already provides clear descriptions, so the description adds marginal value.
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: 'explains how to redeem' a payment by turning a transaction hash into content, and it specifies the output ('Returns the command to run against the merchant's /receipt endpoint'). This is a specific verb+resource combination that distinguishes it from the informational sibling 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?
It provides a clear temporal context: 'After you've signed and sent a payment'. This tells the agent when to use it, but it does not explicitly mention alternatives or when not to use it. Given the sibling list, the context is sufficient for a conditional workflow step.
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 exist, so the description carries the burden. It discloses the lesson topic and content scope, but does not explicitly state that this is a read-only informational tool or describe what the user will see/experience. The 'skip' condition adds behavioral context, but it's more usage guidance than transparency about tool behavior.
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 focused sentences: the first identifies the lesson and provides a precise definition, the second offers a practical skip condition. Every word earns its place with no redundancy.
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?
For a simple informational lesson with no parameters or output schema, the description gives sufficient context: what the lesson covers, how it relates to x402, and who should skip it. It could be slightly more explicit about expected output, but the simplicity of the tool makes this adequate.
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 zero parameters, so the baseline is 4. The description adds useful context about the subject matter and a conditional for usage, which enriches the tool's meaning beyond the empty 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 this is Lesson 13 about AP2 (Agent Payments Protocol), explicitly defining it as the trust/authorization layer above x402 for delegated payments. This distinguishes it from sibling lessons like what-is-x402 and conveys a specific educational resource.
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?
It provides an explicit exclusion ('Skip if you're spending your own funds'), implying use when delegated payments are involved. While it doesn't name alternative tools directly, the contrast with x402 and the skip condition offer practical 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 states the core behavior ('Explains the x402 payment protocol') but does not explicitly disclose whether the tool is read-only, safe, or has side effects. The verb 'explains' implies a non-destructive action, but lacks explicit safety or output details, making it adequate but not rich.
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 short sentences, each serving a purpose: context ('Lesson 7'), function ('Explains x402'), and usage trigger ('Call this if...'). It is front-loaded and concise, with zero wasteful filler.
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 tool is simple with no parameters or output schema. The description provides sufficient context for an agent to understand what the tool does and when to call it. However, it does not explicitly state the format of the returned explanation (e.g., text), which would enhance completeness but is not critical given the simplicity.
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 zero parameters, and the schema description coverage is 100% trivially. Per the rubric, a zero-parameter tool receives a baseline of 4. The description adds no parameter-specific information, but none is needed since there are no 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's purpose: 'Explains the x402 payment protocol in agent-readable terms.' This identifies a specific verb and resource, distinguishing it from sibling lessons. The additional trigger 'Call this if you've hit a 402 response' further clarifies its unique use case.
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 an explicit when-to-use condition: 'Call this if you've hit a 402 response and aren't sure what it means.' However, it does not mention alternatives or exclusions, so guidance is clear but not fully comprehensive. It earns a 4 for explicit context without 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?
With no annotations, the description carries the behavioral disclosure burden. It clearly states the tool's behavior: takes error input and returns a diagnosis and next step. There are no hidden side effects, and the description is honest about the output. It could mention edge cases like unrecognized errors, but for a simple diagnostic tool, the transparency 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?
The description is a single, well-structured sentence with front-loaded imperative ('Paste') and clear outcome ('Returns a diagnosis'). Every phrase earns its place, with no redundancy or filler. It is concise and scannable.
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 tool is simple (2 params, no output schema, no annotations), and the description covers the essential inputs and expected output. It doesn't detail the format of the diagnosis or next step, but given the tool's straightforward nature and high schema coverage, it is sufficiently complete for an agent to select and invoke it correctly.
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%, with both parameters having descriptive text. The description does not add much beyond the schema, but the schema already explains error_text and context well. The description's phrasing mirrors the schema, adding no new parameter-level semantics, so the 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 the tool's function: paste an error message/status/response and receive a diagnosis with a next step. It uses specific verbs ('Paste', 'Returns') and identifies the resource ('x402 attempt'). This distinguishes it from sibling tools like what-is-x402 or get-a-wallet, which are educational or setup-oriented.
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 when to use the tool: when you have an error message or facilitator response during an x402 attempt. It provides clear context for usage but does not explicitly mention alternatives or exclusions, such as 'if you don't have an error, use what-is-x402 instead.' This is a minor gap.
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 the full burden. It explicitly states the tool decodes and returns an explanation, and it enumerates the output content (how much, what asset, which chain, who to pay, what to sign). It does not explicitly address side effects or error handling, but its read-only nature is strongly implied. Omitting explicit 'read-only' and edge-case info prevents a 5.
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 with no redundant words. The first sentence states the purpose and output, the second gives precise input instructions. Every phrase earns its place, 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.
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 parameter, no output schema, no annotations), the description is complete. It explains what the tool does, what input to provide, and what the output will contain. No critical information is missing for an agent to select and use the tool correctly.
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% for the single parameter 'challenge', which already explains it accepts the raw 402 body or the PAYMENT-REQUIRED header. The description repeats this instruction and adds no new semantic detail about the parameter format or variations. 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 the tool's function: it decodes an HTTP 402 x402 payment challenge into a plain explanation, listing the specific elements it extracts (amount, asset, chain, payee, signature). This is a specific verb+resource and distinguishes it from sibling tools that explain concepts rather than decode a given challenge.
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 clear usage context: paste the raw 402 response body or the PAYMENT-REQUIRED header value. It implies this should be used when you have a 402 challenge to understand, and it aligns with the sibling tools' educational nature. However, it does not explicitly mention alternatives or exclusionary conditions, so it does not reach a 5.
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?
There are no annotations, so the description carries the burden of disclosing behavior. It describes the tool as a 'Lesson,' implying informational and read-only behavior. However, it does not explicitly state that there are no side effects or what action occurs when invoked (e.g., showing text or marking a lesson complete). The nature is clear enough for an informational tool, but a bit more explicitness would improve 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, front-loaded with the lesson identifier. The second sentence provides precise subject matter and relational context. Every sentence is informative with no redundancy or filler.
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 simplicity (no parameters, no output schema, no annotations), the description covers the essential topic and relationship between ACP and AP2. It does not describe the exact output or how the lesson is presented, but for a curriculum lesson tool, the stated content scope is sufficient. It could be more complete by mentioning the lesson's outcome, but the current description is adequate for selection and invocation.
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 zero parameters and the schema coverage is 100% (empty schema). Per the rubric, a baseline of 4 is assigned for 0 parameters. The description adds no parameter details because none exist, and that 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 identifies the tool as a curriculum lesson ('Lesson 14') and names the exact subject: ACP (Agent Commerce Protocol) from OpenAI/Stripe. It further specifies the lesson's scope ('How ACP and AP2 relate, when each applies'), which distinguishes it from sibling tools like what-is-ap2 and what-is-x402.
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 states 'when each applies,' providing guidance on when to use this lesson versus AP2-related content. It does not explicitly name alternative tools or state 'use this when...' as a direct exclusion, but the context is clear enough for an agent to select this tool when learning about ACP and its applicability.
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 the burden of disclosure. It transparently explains that the tool is an educational lesson, describes its topic, and notes it assumes no prior knowledge. While it doesn't detail the output format, for a static lesson tool this is sufficient context about what to expect.
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 lesson number and topic, and contains no superfluous words. Every sentence adds value by specifying position in curriculum and prerequisites.
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 low complexity of this educational tool and the empty schema/annotations, the description is adequately complete. It covers what the lesson is, its position, and intended audience. A slightly longer description could mention how it relates to sibling lessons, but the current level is sufficient.
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 zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on the lesson content rather than parameter details, which are nonexistent. No additional parameter semantics are needed.
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 is 'Lesson 1 of the curriculum' and explains its content: 'What a wallet is and what it lets you do.' This distinguishes it from sibling tools like 'what-is-x402' and 'what-is-usdc' which cover other topics, and positions it as the foundational lesson.
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 signals usage by stating it is 'Lesson 1' and 'Assumes no prior knowledge of cryptography or blockchains.' This implies it is the starting point for beginners, but it does not explicitly mention alternative tools or when not to use it, leaving some ambiguity.
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 the full burden of behavioral disclosure. It clearly indicates the tool is instructional ('walks through') rather than performing actual configuration, and it discloses the prerequisite state ('nothing is configured yet'). This is transparent and accurate, though it does not detail any output format or side effects, which are not expected for a lesson-style 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?
The description is two concise sentences. It front-loads the lesson identity, provides the prerequisite command, and summarizes the content without any fluff or redundancy. 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 the tool has no parameters, no output schema, and a simple instructional purpose, the description fully covers the necessary context: what the lesson is, when to use it, and what it covers. No further information is needed for the agent to select and invoke it 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?
The input schema has zero parameters, so the baseline for this dimension is 4. The description appropriately avoids mentioning parameters since there are none, adding no unnecessary information. It does not need to compensate for schema coverage because the schema is complete for an empty parameter set.
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: it is Lesson 5 of a curriculum that walks through which skills to run, in what order, and what each one does. This specific verb+resource combination distinguishes it from sibling lessons like 'what-is-a-wallet' or 'get-a-wallet'.
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 sets the context for when to use it: after running 'npx skills add coinbase/agentic-wallet-skills.' It explains that nothing is configured yet, implying this lesson is a guide for subsequent configuration steps. However, it does not explicitly mention alternatives or when not to use it, so a perfect score is not warranted.
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 the burden of disclosure. It clearly signals non-destructive, educational behavior through words like 'Lesson', 'Explains', and 'walks through', indicating it is informational rather than performing side-effectful actions.
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 concise sentences with no fluff: it states curriculum position, target audience, and specific content. Each sentence adds value, and it is front-loaded with the key identifier 'Lesson 4'.
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 no output schema, the description fully covers what the tool does and what it covers. It gives enough detail for an agent to know exactly when and how to use it without needing additional context.
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 zero parameters, so the description need not explain any. The baseline for 0 parameters is 4, and the description adds no confusion about parameter usage.
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 this is a lesson on installing a wallet, specifically targeting those without one. It distinguishes from siblings like 'what-is-a-wallet' by focusing on installation steps and tooling (npm, npx, skills CLI), not just conceptual explanation.
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 a clear use case: 'if you don't have one' a wallet, and identifies it as Lesson 4 in a curriculum, implying sequential usage. It doesn't explicitly name alternative tools but the use case is well implied.
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 return behavior ('Returns the First Dollar curriculum: fifteen short lessons in order') and the assumed audience ('Assumes no prior knowledge'). It does not describe exact return formatting or side effects, but for a read-only educational tool this is sufficient.
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: an engaging opening that states when to start, a precise statement of the returned curriculum with a sample range, and a final note on prerequisites. Every sentence earns its place, with no wasted words or repetition.
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?
For a zero-parameter, no-output-schema informational tool, the description is complete. It covers purpose, usage triggers, what is returned (including lesson count and ordering), and the knowledge assumptions. Sibling tools are specific subtopics, and this description adequately fills the role of a central onboarding/index 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 tool has zero parameters, and schema coverage is effectively 100%. The baseline for no parameters is 4, and the description correctly omits any parameter details since none exist. It adds no conflicting or confusing parameter information.
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 function with a specific verb ('Returns') and resource ('First Dollar curriculum'), and identifies the target audience (beginners or users hitting a 402). It distinguishes itself from sibling tools by being the entry point that provides an ordered curriculum rather than a single topic.
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 clear when-to-use conditions: 'Start here if you want to learn how to spend your own money for the first time, or if you hit a 402 and aren't sure what to do.' It lacks explicit exclusions or named alternatives, but the context implies that specific topic tools (siblings) are for narrower questions, making the usage guidance strong.
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:

[![firstdollar MCP server](https://glama.ai/mcp/servers/lisamaraventano-spine/firstdollar/badges/card.svg)](https://glama.ai/mcp/servers/lisamaraventano-spine/firstdollar)

Score Badge

Copy to your README.md:

[![firstdollar MCP server](https://glama.ai/mcp/servers/lisamaraventano-spine/firstdollar/badges/score.svg)](https://glama.ai/mcp/servers/lisamaraventano-spine/firstdollar)

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/lisamaraventano-spine/firstdollar'

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