Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Habitscore score our nightly ETL pipeline's reliability and rank the fixes by priority"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Habitscore — analytics over anything with a recurring completion history.
Two families of tools, one engine:
Operational reliability — score recurring tasks, jobs, pipelines and scheduled workflows. Success rate, streak recovery, lapse risk, latency-trend warnings, and remediation ranked by priority.
Behavioural analytics — the same scoring over habit and routine data. Adherence, consistency, momentum, lapse risk, next-best actions, multi-week plans.
Pays per call with x402: USDC on Base, no account, no API key, no subscription. From $0.03 per call.
Walkthrough with a working x402 client example: https://mydev-tools.tech/agents/reliability/
The server runs on your machine with your wallet. It signs payments locally and the private key never leaves the process. Nothing is custodied on our side and there is no account to create — the same promise the HTTP API makes.
Without a wallet configured, every tool still works in quote-only mode: it returns the price and the payment terms instead of erroring, so you can see what a call would cost before funding anything.
Related MCP server: loophole-tape
// Claude Desktop: claude_desktop_config.json
// Cursor: ~/.cursor/mcp.json
{
"mcpServers": {
"habitscore": {
"command": "npx",
"args": ["-y", "habitscore-mcp"],
"env": {
"HABITSCORE_PRIVATE_KEY": "0x…",
"HABITSCORE_MAX_SPEND_USD": "0.25"
}
}
}
}Omit HABITSCORE_PRIVATE_KEY to start in quote-only mode.
Use a dedicated wallet holding only what you intend to spend. Fund it with a small
amount of USDC on Base (contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913). You do not
need ETH: under EIP-3009 you sign the authorisation off-chain and the facilitator submits
the transaction and pays the gas.
HABITSCORE_MAX_SPEND_USD caps what a single tool call may spend, and is checked against the
price the server actually quotes before anything is signed. An agent loop that retries a
paid tool can otherwise spend without bound, and you are the one paying — so a server that
quotes more than you authorised is refused rather than paid.
Tool | Price | Returns |
| $0.08 | Reliability score and grade per task, lapse risk, latency-trend warnings, priority-ranked remediation |
| $0.05 | Adherence and consistency scores, streak momentum, lapse-risk flags, highlights, watchouts, recommendations |
| $0.03 | Ranked next-best action per habit with rationale and priority |
| $0.05 | Condensed patterns, correlations and risk signals |
| $0.10 | Multi-week plan for one habit: weekly targets and dated milestones |
Price is per call, not per habit. analyze_behaviour accepts up to 25 habits for the
same $0.05, so batching is by far the cheapest way to use this.
Reliability:
{
"system": "billing-pipeline",
"tasks": [
{
"name": "nightly-etl",
"success_rate": 0.83,
"current_streak": 0,
"best_streak": 52,
"runs": 210,
"latency_trend": "rising",
"p95_latency_ms": 38000,
"cadence": "daily",
"critical": true
}
]
}name, success_rate (0–1), current_streak and best_streak are required. Note that
latency_trend: "rising" is the degradation signal — the opposite polarity to the
behavioural tools, where a falling trend is the warning.
Behavioural:
{
"habits": [
{
"name": "Morning run",
"completion_rate": 0.72,
"current_streak": 9,
"best_streak": 21,
"average_mood": 7.4,
"energy_trend": "rising"
}
]
}name, completion_rate (0–1), current_streak and best_streak are required. average_mood,
mood_correlation, energy_trend and risk_score are optional and sharpen the result.
"Habit" is the domain vocabulary, but the analysis applies to any recurring activity with completion history — training schedules, medication adherence, study routines, recurring operational tasks.
The engine is deterministic and CPU-only: threshold rules and arithmetic over the numbers you supply. Same input, same output, every time.
It is not a language model and does not generate prose beyond composing its findings. It does not store anything — the agent endpoints are stateless, accept no user identifier, and cannot read or infer any stored history. It is not medical, psychological or financial advice.
Variable | Default | Purpose |
| — | Wallet key for signing payments. Omit for quote-only mode. |
|
| Hard cap per tool call, enforced before signing. |
|
| API origin. |
|
| Base RPC for balance reads and signing context. |
Every successful paid call appends the settlement transaction hash to the tool output. Open it on basescan.org to confirm the amount and recipient independently of anything this server reports.
Overview: https://mydev-tools.tech
Capabilities: https://api.mydev-tools.tech/v1/capabilities
Pricing and volume rebate: https://api.mydev-tools.tech/agent/v1/pricing
Verified spend earns credits back — 5% from $10 lifetime, 10% from $100, 15% from $1,000,
with higher rate limits at each tier. Credits are returned inline in the response that earns
them and are redeemed with an X-Agent-Credit header on a later call.
MIT licensed.
Behavioural analysis over up to 25 habits or recurring activities in one call. Returns adherence and consistency scores, streak momentum, lapse-risk flags, highlights, watchouts and recommendations. Use for adherence monitoring, routine optimisation, engagement and churn-risk signals, and streak analysis. Costs $0.05 in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| habits | Yes | Up to 25 habits. Price is per CALL, not per habit — batch aggressively, sending 25 costs the same as sending one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose the upstream cost ($0.05 USDC on Base), the per-call (not per-habit) pricing model, and what the analysis produces. What it omits is payment mechanics (how the x402 charge is settled) and whether anything is persisted, which matters for a paid call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler: what it does, what comes back, when to use it, what it costs. Every clause carries new information and the cost, the most decision-relevant fact, is left where it belongs, at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the return payload (adherence, consistency, streak momentum, lapse-risk flags, highlights, watchouts, recommendations). Only the payment/settlement path for the USDC charge is left unexplained, which is a real gap for a paid tool but not a blocking one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every per-habit field already has a description, so the baseline is 3. The description earns a bump by supplying the actual price and currency, which the schema only alludes to as 'price is per CALL' — that number is what drives the batching decision.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (behavioural analysis over habits/recurring activities) and names the unit of work and the cap (up to 25 in one call). An agent can distinguish it from analyze_reliability or build_habit_plan without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists plausible use cases (adherence monitoring, routine optimisation, engagement/churn signals, streak analysis), which implies when to reach for it. But it never names siblings like analyze_reliability or recommend_next_actions, so the agent gets no explicit guidance on when this tool is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reliability analysis for up to 25 recurring tasks, jobs, pipelines or scheduled workflows in one call. Returns a reliability score and grade (healthy/degrading/unstable/failing) per task, lapse risk, streak recovery, latency-trend warnings, and remediation actions ranked by priority so the list is actionable top-down. Use for cron and pipeline monitoring, flaky-job triage, SLA and uptime adherence, agent task reliability, and deciding what to fix first. Deterministic threshold analysis over the figures you supply — no model, no log parsing, no root-cause inference. Costs $0.08 in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Price is per CALL, not per task — sending 25 costs the same as sending one. | |
| system | No | Optional label to correlate the response with a system. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden well: it discloses the scoring approach, output categories, ranked remediation actions, lack of model/log parsing/root-cause inference, and per-call cost. It stops short of explicitly stating side effects, data retention, or authorization requirements, but the analysis-only framing is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well structured: it front-loads purpose and scope, then summarizes outputs, usage cases, analytical limitations, and cost. Every sentence contributes useful selection or invocation context without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides enough context for an agent to call this correctly: input scope, returned analytical categories, deterministic methodology, limitations, and cost are all stated. It is complete for the complexity of a read-only analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the nested task fields are already well documented. The description reinforces the 25-task limit and per-call pricing, but those details are also present in the schema, so it does not add substantial parameter meaning beyond structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: reliability analysis for recurring tasks, jobs, pipelines, or scheduled workflows. It also defines the output shape and explicitly contrasts itself with model-based inference, log parsing, and root-cause analysis, which helps distinguish it from siblings such as analyze_behaviour and extract_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear use cases: cron and pipeline monitoring, flaky-job triage, SLA and uptime adherence, agent task reliability, and prioritization. It also clarifies what the tool does not do, but it does not explicitly name sibling alternatives or 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.
Multi-week plan for ONE habit: weekly targets and dated milestones over a chosen horizon. The most compute-intensive endpoint. Costs $0.10 in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| habit | Yes | ||
| horizon_days | No | Planning horizon in days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose that this is the most compute-intensive endpoint and costs $0.10 in USDC on Base. However, it does not explain payment flow, authentication, whether the operation creates persistent state, or what the caller receives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no wasted language. Purpose and scope are front-loaded, and the cost note follows naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and cost, and briefly indicates the plan contains weekly targets and dated milestones. But for a paid, compute-intensive endpoint with no output schema and no annotations, it leaves important invocation context unspecified, including payment mechanics and the exact return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds little beyond clarifying that the habit input is for ONE habit and that the horizon is chosen. It does not explain the required nested habit fields or how optional metrics such as risk_score and mood_correlation affect the plan.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: build a multi-week habit plan for one habit, with weekly targets and dated milestones over a chosen horizon. It is clearly distinct in kind from analysis/recommendation siblings, though it does not explicitly differentiate itself from them by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for a single habit over a chosen horizon, but gives no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as recommend_next_actions or analyze_behaviour. The cost note is useful context but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Condensed behavioural highlights and watchouts — patterns, correlations and risk signals — without the full aggregate breakdown. Use when you want the narrative rather than the numbers. Costs $0.05 in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| habits | Yes | Up to 25 habits. Price is per CALL, not per habit — batch aggressively, sending 25 costs the same as sending one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the cost ($0.05 USDC on Base) and that this is a paid call — valuable context most tools omit. However it says nothing about payment/auth mechanics, whether the operation is read-only/computational, or what the response actually looks like, and the useful 'price is per CALL, batch aggressively' advice lives only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: what it returns, when to pick it, what it costs. The value proposition is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, single-parameter compute tool with no output schema, the description gives only a loose sketch of the return shape ('highlights and watchouts') and omits payment flow and output structure details. It is adequate to select and call the tool, but not to predict its response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every field of the single `habits` parameter is documented in-schema, including the batching economics. The description adds no parameter meaning beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete deliverable — condensed behavioural highlights, watchouts, patterns, correlations and risk signals — and explicitly distinguishes it from the 'full aggregate breakdown' produced elsewhere. The verb is implicit (no 'extract'/'return'), and no sibling is named, but an agent can infer this is the narrative-summary counterpart to the numeric analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use when you want the narrative rather than the numbers' is an explicit selection cue that contrasts with the aggregate-report siblings. It lacks named alternatives (analyze_behaviour, analyze_reliability) and any when-not conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked next-best action per habit, each with a rationale and a priority score. The cheapest endpoint, deterministic and CPU-only, so it is suitable for high-frequency loops. Costs $0.03 in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| habits | Yes | Up to 25 habits. Price is per CALL, not per habit — batch aggressively, sending 25 costs the same as sending one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses determinism, CPU-only execution, per-call pricing ($0.03 USDC on Base), and the key billing quirk that cost is per CALL not per habit. Missing are error behavior, latency, and whether results are cached/idempotent across identical inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool returns, then cost/performance traits. No filler and no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, but the description covers purpose, return shape, determinism, cost model, and batching guidance — enough to call it correctly. A brief note on what an empty or low-confidence result looks like would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `habits` parameter is documented field-by-field, so the baseline is 3. The batching economics are useful but already live in the schema's own description, so the tool description adds no param meaning beyond structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and output shape: 'Ranked next-best action per habit, each with a rationale and a priority score.' An agent knows exactly what it gets back. It does not, however, differentiate itself from the closest sibling build_habit_plan, leaving ambiguity about recommendations vs. a full plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'The cheapest endpoint, deterministic and CPU-only, so it is suitable for high-frequency loops' gives a concrete usage context (cheap, repeatable, loop-friendly) that helps an agent pick this over pricier siblings. It stops short of naming alternatives or stating 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1analyze_behaviouranalyze_reliabilitybuild_habit_planextract_insightsrecommend_next_actionsScored across 5 tools
analyze_behaviour, extract_insights and recommend_next_actions all operate on the same habit data and return overlapping artefacts (highlights, watchouts, recommendations), so the boundary between 'full analysis', 'narrative only', and 'next actions only' requires reading descriptions carefully. analyze_reliability vs analyze_behaviour is clearer (tasks/jobs vs habits) but still conceptually adjacent.
All five names follow a strict verb_noun snake_case pattern (analyze_*, recommend_*, extract_*, build_*), so intent and grouping are immediately predictable. No mixed camelCase or vague single-word verbs.
Five tools is well within a healthy scope for an analysis-only service and each maps to a distinct output tier. Slight redundancy: extract_insights looks like a trimmed slice of analyze_behaviour rather than an independent capability.
Coverage is analysis-only: there is no way to record, update or query stored habit/task data, so every call must supply its own figures. Planning exists for a single habit but not for task/pipeline remediation or multi-habit plans, which leaves some obvious lifecycle gaps.
Statistical adjudication for agents: backtest judges, fact-checks. Pay per call in USDC via x402.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Paid per call over x402: growth coaches, small utilities and real-world actions. USDC on Base.
17 pay-per-call web, finance, legal and onchain tools for AI agents. USDC on Base via x402/MPP.
