Summary: The server exposes AAJ Marketing Engines' deterministic, offline marketing calculators and skill library to an MCP client — letting an agent discover engines, inspect their inputs, run the math on real numbers, and look up marketing methods.
List engines (list_engines): enumerate all runnable engines with id, question answered, and category, optionally filtered by keyword (e.g. "pricing", "retention", "seo audit").
Describe an engine (describe_engine): fetch one engine's input schema — required fields, units, alternative shapes, and a worked example.
Run an engine (run_engine): compute a verdict from your own inputs, or omit input to run the built-in demo; deterministic, offline, and validates input (wrong units error out rather than silently guessing).
Search skills (search_skills): find marketing skills by plain-language problem (e.g. "churn is rising", "not showing up in AI answers"), with a result limit, flagging which have runnable engines.
Get a skill (get_skill): retrieve a skill's full method — when to use it, steps, quality bar, and how to run its engine.
Domain coverage: unit economics/LTV:CAC, pipeline forecasting, budget allocation, retention/NRR, A/B significance, SEO/GEO/AEO scoring, ad spend, pricing, and more across ~66 engines and ~81 skills.
Safety properties: all tools are read-only, non-destructive, idempotent, and closed-world (no network calls or side effects).
Provides a recipe to feed HubSpot deal data into the pipeline-and-forecast engine, enabling weighted forecasting, pipeline coverage checks against win rates, and identifying levers to improve the forecast.
Provides a recipe to use Semrush keyword data with the aaj-programmatic-seo skill to evaluate whether a template-page build pays back.
Provides a recipe to use Stripe export data with the unit-economics engine to compute gross-margin LTV, CAC payback, and whether the economics support growth.
Most marketing skills are writing instructions. They help an agent draft a page, an email or a plan, so keep them. These add the arithmetic underneath. The agent that drafts your pricing page can check whether the price still covers inference cost. The agent that writes the board update can compute the forecast instead of estimating it. Same input, same output, and code you can read.
Works with Claude Code, OpenAI Codex, Cursor, Windsurf, Cline and any agent that supports the Agent Skills spec. Free, MIT, no API key, and the engines make no network calls.
Built by Saroj Jha / AAJ. Browsable library at skills.aajconsult.com.
If an engine saves you a spreadsheet, star the repo. Stars are how other founders, and the directories agents search, find it. Questions and engine requests go in Discussions.
Renamed on Oct 11, 2026.
copywriting,marketing-psychology,programmatic-seo,marketing-loopsandsales-enablementare nowaaj-copywriting,aaj-marketing-psychology,aaj-programmatic-seo,aaj-marketing-loopsandaaj-sales-enablement. Another popular library publishes skills under the same five names, so with the prefix both install side by side. The hosted MCP server still answers to the old names.
Strategy & Positioning — 15 skills, 10 engines
Research & Personas — 4 skills, 3 engines
SEO, GEO & AEO — 10 skills, 9 engines
Content & Copy — 11 skills, 10 engines
Conversion & Web — 6 skills, 4 engines
Paid Media & Budgeting — 5 skills, 5 engines
Analytics & Experimentation — 5 skills, 5 engines
Sales & Pipeline — 12 skills, 9 engines
Retention & Lifecycle — 3 skills, 2 engines
Growth, Retention & RevOps — 10 skills, 9 engines
Related MCP server: mcp-saas-metrics
# everything
npx skills add sarojkjha/aaj-marketing-skills
# one skill
npx skills add sarojkjha/aaj-marketing-skills --skill unit-economics
# see what's available
npx skills add sarojkjha/aaj-marketing-skills --listInstalls to .agents/skills/, and symlinks into .claude/skills/ for Claude Code.
Step-by-step instructions for every agent, Windows, Mac and Linux, and the hosted server: docs/install.md.
Then run any engine with no configuration at all:
node .agents/skills/unit-economics/resources/unit-economics.js --demoAAJ Unit Economics -- subscription
------------------------------------------------------
Gross-margin LTV $13,333 (3.0% monthly churn (~33.3 mo lifetime))
CAC $3,000
LTV : CAC 4.4:1
CAC payback 7.5 mo
[OK] LTV:CAC 4.4:1 is at or above the 3:1 floor.
[OK] CAC payback 7.5 mo is within the ~12-month guideline for subscription.Swap the demo values for your own and it works the same way.
From a clone of this repo, paths are
skills/<slug>/resources/…instead of.agents/skills/<slug>/resources/….
Claude Code. In Claude Code 2.1.275 or later, one line adds the marketplace and opens the plugin:
/plugin install aaj-marketing-skills --marketplace sarojkjha/aaj-marketing-skillsOn earlier versions, run two commands:
/plugin marketplace add sarojkjha/aaj-marketing-skills
/plugin install aaj-marketing-skills@aajThe skills then appear as /aaj-marketing-skills:<skill>. The plugin also starts the local AAJ engines MCP server (platform/mcp/server.mjs, Node 18+), so Claude can call run_engine directly. It runs on your machine and AAJ receives nothing. Updates arrive when you run /plugin marketplace update aaj.
OpenAI Codex. Add the marketplace, then install the plugin (or browse it with /plugins inside Codex):
codex plugin marketplace add sarojkjha/aaj-marketing-skills
codex plugin add aaj-marketing-skills@aajcodex plugin marketplace upgrade aaj picks up new skills. Codex reads .agents/plugins/marketplace.json, and both clients load every skill in skills/.
Instead of installing the skills into a project, you can expose all 81 skills and all 66 engines to any MCP client — Claude Desktop, Claude Code, Cursor, Windsurf — as five tools:
Tool | What it does |
| Every runnable engine, grouped by category |
| One engine's input schema, units and worked example |
| Runs it on your numbers, or the demo if you pass none |
| Finds a skill by the problem, not the name |
| The full method for one skill |
Hosted, no install. Add this URL as a custom connector (a remote MCP server) in Claude, ChatGPT or any MCP client:
https://aaj-engines-mcp.sarojkjha10.workers.dev/mcpNo sign-in. The server runs the engines in memory and keeps no copy of what you send (what happens to your data). In Claude: Settings → Connectors → Add custom connector. Then ask, for example, "Use the AAJ engines to check my unit economics: CAC $1,200, ARPA $300 a month, 80% gross margin, 3% monthly churn."
Local. Clone the repo and point your client at one file. Node 18+, no dependencies, no build step:
{
"mcpServers": {
"aaj-engines": {
"command": "node",
"args": ["/absolute/path/to/aaj-marketing-skills/platform/mcp/server.mjs"]
}
}
}Your agent can then find the right method for a problem and run the math on your numbers, rather than estimating. Run locally, AAJ receives nothing; your agent's model provider still sees what you give the agent.
The engines are deterministic scripts. They make no network calls, write no files and take no actions in your tools; they compute and return text and JSON. Where your numbers travel depends on how you run them:
How you run it | Where your inputs go |
Skill installed in your agent, or the local MCP server | The engine runs on your machine and AAJ receives nothing. Your AI agent still sends what you give it to its model provider (Anthropic, OpenAI and so on), under your own account's terms. |
Hosted MCP server | Your agent's model provider, as above, plus AAJ's server on Cloudflare, which receives the engine inputs over HTTPS, runs them in memory and keeps no copy. Cloudflare keeps error logs (no inputs) for up to 7 days. |
Don't pass customer names, emails or other personal data to an engine; none of them needs it.
Setup for each client, troubleshooting, and the smoke test:
platform/mcp/README.md.
Vendor MCP servers bring the data; the engines turn it into a verdict. Each recipe is a prompt to paste, a field-by-field mapping and the checks to make before you trust the result:
HubSpot deals into pipeline-and-forecast: weighted forecast, coverage against your win rate, and the lever to pull.
GA4 results into ab-test-significance: sample size before the test, a verdict after it.
Ahrefs or Semrush keyword data into aaj-programmatic-seo: whether a template-page build pays back.
Stripe export into unit-economics: gross-margin LTV, CAC payback, and whether your economics support growth.
Most agent skills are instructions. These are too — but 66 of them also ship a dependency-free Node script that does the arithmetic and returns a judgement.
Instruction-only skill | Skill with an engine | |
Output | Guidance the agent paraphrases | Deterministic numbers |
Reproducible | No | Yes — same input, same output |
Verifiable | You trust the model | You read the code |
Runs without an agent | No | Yes, |
Every engine accepts --demo (a worked example, no config), --help (the input schema), and a JSON payload for your own numbers. Engines validate input and fail loudly rather than returning a confident wrong answer.
E marks a skill with a runnable engine. Phase refers to AAJ's Diagnose → Design → Execute method.
Skill | What it does | Phase | |
E | Diagnoses which decision friction blocks the buyer, with a line between persuasion and manipulation. | Design | |
E | Checks that an AI plan's price still covers inference when usage spikes. | Design | |
E | Picks the segment to win first from evidence, and says when the pick is still a guess. | Design | |
Builds the shared brand brief every other skill reads first. | Diagnose | ||
E | Diagnoses which play applies, then sequences the other skills in order. | Diagnose | |
E | Reads rival homepages side by side and says which claims are crowded, which are open, and whether your headline blends in. | Diagnose | |
Builds the GTM story an investor can check, from engine-run numbers. | Design | ||
E | Sizes TAM, SAM and SOM bottom-up, with SOM set by capacity rather than a share of the market. | Diagnose | |
E | Scores marketing as a system across six dimensions, and names the weak links to fix first for your stage. | Diagnose | |
Structures the message hierarchy beneath the positioning. | Design | ||
E | Produces a positioning statement pressure-tested against the competitive alternative. | Design | |
E | Designs tiers with an anchor check and a willingness-to-pay read. | Design | |
E | Scores a pricing page on 21 buyer checks, and says whether a price test can answer the question at your traffic. | Diagnose | |
Chooses self-serve, sales-led or a mix from the buyer and the unit economics, not from fashion. | Design | ||
Sharpens the value proposition into something defensible. | Design |
Skill | What it does | Phase | |
E | Turns coded interview notes into ranked patterns and anecdotes, and says whether you can stop interviewing. | Diagnose | |
E | Designs surveys that produce usable answers, with sample sizing and segments. | Diagnose | |
Builds personas from evidence rather than imagination. | Design | ||
E | Codes pasted reviews of you and your rivals into themes, switching reasons, feature asks and buyer language. | Diagnose |
Skill | What it does | Phase | |
E | Models whether a template-page build pays back before anything gets written. | Design | |
E | Scores whether an AI agent buying for a customer can find, evaluate and transact with you. | Diagnose | |
E | Separates ChatGPT, Perplexity, Gemini and Copilot visits in a GA4 export, and says whether they really convert differently. | Diagnose | |
E | Sorts a Search Console export into decaying, demand-drop, snippet-loss, rising and stable pages, and ranks what to refresh by clicks lost. | Diagnose | |
E | Measures whether AI engines name and cite you, and refuses to report noise as movement. | Execute | |
Rewrites a page to maximise the chance an AI engine cites it. | Execute | ||
E | Reads a Search Console Queries export by intent and topic, and names the demand you already appear for but do not yet win. | Diagnose | |
E | Produces a writer-ready brief: intent, answer block, entities, internal links. | Design | |
E | Scores a page 0-100 across SEO, GEO and AEO, with fixes in priority order. | Diagnose | |
E | Maps schema types to pages, then checks each page's JSON-LD against Google's docs and the visible text. | Execute |
Skill | What it does | Phase | |
E | Rewrites page copy to ladder to the positioning, scored on claim-defensibility. | Execute | |
E | Scores whether a team's AI use is governed, and refuses citations that cannot be checked. | Execute | |
E | Derives the measurable half of a voice guide from writing you agree sounds right, as a checkable profile. | Design | |
E | Checks content block by block against your own voice rules, with a pass/revise verdict. | Execute | |
E | Scores whether proof would convince a sceptic, and whether you may publish it at all. | Execute | |
E | Flags every claim in your copy that needs proof or consent, sentence by sentence, with the regulator's own guidance. | Execute | |
E | Builds vs and alternatives pages with sourced, dated rival facts, and checks they admit where the rival wins. | Execute | |
E | Costs a content plan in hours against real capacity, and names what to cut. | Execute | |
Turns one pillar asset into channel-adapted derivatives, reusing only what it says. | Execute | ||
E | Scores a founder's channel setup, and checks a post against the themes only they can write. | Execute | |
E | Scores a story before it is pitched, and aims it at twenty of the right people. | Execute |
Skill | What it does | Phase | |
Specs a landing page before anyone designs it. | Execute | ||
E | Scores lead-magnet and free-tool ideas on the job they do against build effort, and judges live ones on qualified leads. | Design | |
E | Reads each upgrade prompt's funnel with honest intervals and names the prompt and stage to fix first. | Diagnose | |
Picks the demo format for each buying stage and keeps AI demos honest. | Design | ||
E | Scores signup friction and ranks what to remove by what it's worth. | Execute | |
E | Audits a page for conversion friction and grades it. | Diagnose |
Skill | What it does | Phase | |
E | Sizes a creative test before it runs, and refuses to name a winner the data cannot back. | Execute | |
E | Says how much to spend, and for how long, before judging a channel - and when to stop early. | Design | |
E | Sizes a marketing budget by stage, shows where each figure comes from, and splits it by function. | Design | |
E | Splits spend across channels to hit a CAC target, with diminishing returns modelled. | Design | |
E | Audits a search account against its own target: tracking, waste, starved winners, pages. Fixes ranked by spend. | Diagnose |
Skill | What it does | Phase | |
E | Checks whether an A/B result is significant, or sizes a test before you run it. | Execute | |
E | Designs and reads holdout tests honestly, including whether they could ever have answered. | Diagnose | |
E | Turns funnel, spend and pipeline numbers into a board-ready narrative. | Execute | |
E | Magic number, burn multiple, Rule of 40 and CAC payback, each read against its source's own words. | Diagnose | |
E | Computes LTV, CAC, payback and the ratio, then returns a verdict against named reference points. | Diagnose |
Skill | What it does | Phase | |
E | Audits sales assets against what each deal stage needs, and ranks what to build by the revenue being lost. | Execute | |
E | Checks whether the team can run the account list and whether the list hits the number. | Design | |
E | Maps who must say yes, what each must believe, and who you cannot reach, then orders the next conversations. | Design | |
Writes outbound sequences that survive a reply-rate audit. | Execute | ||
Structures discovery so the call qualifies rather than pitches. | Execute | ||
E | Checks whether MQLs get worked on time, whether sales takes them, and whether the threshold is in the right place. | Execute | |
E | Builds responses to the objections that lose deals, and checks the battlecard before reps use it. | Design | |
E | Plans a pilot backwards from the buyer's budget date, so a pilot that works becomes a contract. | Design | |
E | Weights pipeline by stage and says whether coverage is real. | Execute | |
Designs the stages and exit criteria a forecast can rely on. | Design | ||
E | Scores and tiers accounts by ICP fit, showing the signals each matched. | Design | |
E | Finds the Pareto of why deals are actually lost, by revenue. | Diagnose |
Skill | What it does | Phase | |
E | Maps which lifecycle sequences exist, checks send load, writes the missing ones. | Execute | |
E | Computes churn, NRR, GRR and quick ratio, then diagnoses which one to fix. | Design | |
Defines the activation moment from data and finds where new users stall. | Execute |
Skill | What it does | Phase | |
E | Computes the loop factor, finds the throttling stage, projects users over time. | Design | |
E | Maps where buyers already talk, decides whether to open your own community, and measures dark social by asking. | Execute | |
E | Pays creators for the buyers they reach, not their follower count, and judges the result on what it sold. | Execute | |
Treats docs and the first working call as the marketing, and measures it. | Design | ||
E | Writes the first marketer's scorecard, then scores the panel's evidence and calls hire, no-hire or more evidence. | Design | |
E | Prices in-house, fractional and agency with ramp, search time and your own hours, and says which shape fits. | Diagnose | |
E | Scores partners on audience overlap rather than fame, and judges the result on pipeline. | Execute | |
E | Tiers a launch, scores readiness on a twelve-item gate, and builds the dated work-back plan. | Execute | |
E | Designs who to ask and what to reward, then prices referral against the CAC it replaces. | Design | |
E | Sizes a webinar backwards from the pipeline it must create, and judges it on meetings and pipeline against cost. | Execute |
Every runnable engine, and the command to try it:
Skill | Command |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Every skill is tagged to a phase, and the ordering is deliberate — the catalog refuses to let you execute before you have diagnosed.
Diagnose (22 skills) — find out what is actually broken before choosing a fix.
Design (29 skills) — decide the approach, with the trade-offs stated.
Execute (30 skills) — build and ship it.
If you do not know where to start, campaign-orchestrator diagnoses which play applies and sequences the rest for you.
New to the catalog? Run brand-product-context first. It builds the shared brief every other skill reads.
See AUTHORING_GUIDE.md for the standard every skill follows, and SKILL_TEMPLATE.md to start a new one.
MIT — use freely, commercially or otherwise.
Built by Saroj Jha / AAJ, a marketing consultancy for Seed–Series B startups. The Agent Skills spec and Corey Haines' coreyhaines31/marketingskills (MIT) were references for structure and topic coverage; all AAJ skills are independently written and grounded in AAJ's own tools and methodology.
Shows one engine's input schema: required fields, units, alternative shapes, and a worked example. Engines reject bad input rather than guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | Yes | Engine id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description adds a genuinely useful behavioral trait not in the annotations: engines fail fast on invalid input rather than coercing or guessing, which tells the agent to treat the schema as strict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing: the first front-loads what is returned, the second adds the fail-fast behavior. No filler, no restatement of the tool name or title.
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 one-parameter, read-only lookup with no output schema, the description covers purpose, return content, and the validation behavior. It is nearly complete, lacking only a pointer that engine ids come from list_engines.
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?
There is a single parameter ('engine') with 100% schema description coverage, so the schema already documents it as an engine id. The phrase 'one engine's input schema' confirms the parameter selects which schema is returned but adds no format or sourcing detail beyond the schema.
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 — 'Shows one engine's input schema' — and enumerates what the output contains (required fields, units, alternative shapes, worked example). This clearly separates it from list_engines and run_engine, though it never names a sibling explicitly.
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?
Usage is only implied: the note 'Engines reject bad input rather than guessing' hints that this should be consulted before calling run_engine with unfamiliar arguments, but no explicit when-to-use instruction or alternative is offered. An agent can infer the workflow but must do the inference itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full method for one skill: when to use it, the steps, the quality bar, and how to run its engine if it has one.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Skill slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, idempotent read operation. The description adds useful context about the return payload, including steps, quality bar, and engine-run instructions when present, though it does not mention error behavior or missing-skill handling.
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?
A single well-formed sentence with no filler. The return contents are front-loaded and the description is appropriately sized for a simple lookup tool.
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 one-parameter read-only lookup with rich annotations and no output schema, the description adequately explains what the agent will receive. It could be slightly stronger by mentioning failure behavior for an unknown skill, but the core retrieval contract is clear.
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 'skill' slug parameter is fully documented in the schema. The description adds only the notion of 'one skill' and does not contribute additional format or constraint details beyond the schema.
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 resource: returns the full method for one skill. It clearly distinguishes itself from search_skills by specifying a single skill lookup and details the payload contents.
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?
Provides no explicit when-to-use guidance or alternatives. The phrase 'when to use it' refers to the skill's own method content, not to when an agent should call get_skill rather than search_skills or run_engine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every AAJ marketing engine: its id, the question it answers, and its category. Engines cover unit economics, pipeline forecast, budget allocation, retention, A/B significance, SEO/GEO scoring, ad spend and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional filter. Words are matched against the engine's category, id and skill title (for example "pricing", "retention" or "seo audit"), then against its summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing the shape of each returned entry (id, question, category) and the breadth of engine topics, which matters because there is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the core purpose and returned fields front-loaded ahead of the topical coverage list. Every clause carries information.
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 usefully compensates by naming the fields each engine entry carries and the categories covered. It omits pagination, result counts, and whether engines can be unavailable/disabled, but it is otherwise sufficient for a zero-required-parameter read tool whose annotations cover safety.
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 optional 'category' parameter is thoroughly documented there, including the matching behavior and fallback to summary. The description adds nothing about the parameter, so the baseline of 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?
States a specific verb and resource ('Lists every AAJ marketing engine') and enumerates the fields returned (id, question, category) plus the domain coverage. It implicitly distinguishes itself from run_engine/describe_engine by being the enumeration endpoint, but never names a sibling explicitly, so it falls short of a 5.
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?
Usage is only implied: an agent can infer this is the discovery call to make before describe_engine or run_engine, but the description never says when to use it, when not to, or what alternative exists. No prerequisites or sequencing guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs an AAJ engine and returns its verdict. Give input as an object of the engine's fields. Omit input to run the engine's built-in worked example. Engines are deterministic, offline, and validate their input — a wrong unit is reported as an error, not absorbed into a confident answer.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | The engine's configuration object. Some engines also accept a named mode as a plain string (for example 'design' or 'readout'). Omit for the demo. | |
| engine | Yes | Engine id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real value: deterministic execution, offline operation, and input validation that surfaces unit errors instead of masking them. It stops short of describing error or verdict shape, so a 4 rather than 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, zero filler, with the core action and the demo shortcut front-loaded. Each sentence contributes a distinct fact: what it does, how to call it, and how it behaves on bad input.
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 only two parameters, no output schema, and full schema coverage, the description supplies the missing behavioral context (determinism, offline, validation). It does not clarify what a 'verdict' contains, but the absence of an output schema makes that gap modest.
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%, so both parameters are already documented, including the string-mode variant for `input`. The description restates that `input` is an object of the engine's fields and can be omitted, adding little beyond the schema; 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 opens with a specific verb and resource: "Runs an AAJ engine and returns its verdict." That is clearly distinguishable from describe_engine and list_engines, which inspect rather than execute. It does not name those siblings explicitly, which keeps it just short of a 5.
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 concrete usage conditions: pass `input` for a configured run, omit it to invoke the built-in worked example. There is no explicit when-not guidance or pointer to describe_engine/list_engines for discovering engine ids, so the routing decision is only partly covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds AAJ marketing skills by the problem they solve — 'churn is rising', 'we're launching next month', 'not showing up in AI answers'. Returns matching methods and marks which have a runnable engine.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 8. | |
| query | Yes | The problem, in plain words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world). The description adds genuinely useful behavioral context by describing the return: matching methods marked with whether a runnable engine exists, which is meaningful given no output schema exists.
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?
Front-loaded with purpose, then a compact return clause; the quoted problem examples are illustrative rather than filler and earn their place. No wasted sentences.
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 two-parameter search tool with full schema coverage and no output schema, the description supplies enough: what it searches, what it returns, and how to phrase input. Only the absence of explicit sibling routing keeps it from being fully complete.
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 both the query and limit parameters are already documented. The description reinforces the query semantics ('the problem, in plain words') but adds no syntax or constraint detail beyond the schema; 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?
States a specific verb ('Finds') plus resource ('AAJ marketing skills') and a distinguishing mechanism ('by the problem they solve') with concrete query examples. It reads clearly as a semantic search rather than a list/lookup, though it doesn't explicitly name the siblings it differs from.
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?
Usage is implied by the problem-phrased query examples — an agent can infer it's for phrasing a need in plain words. However, there is no explicit when-to-use/when-not statement and no routing to alternatives like list_engines or get_skill.
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.
v0.1.0describe_engineget_skilllist_enginesrun_enginesearch_skillsScored across 5 tools
Each tool has a distinct role: list/search for discovery, get_skill/describe_engine for detail, run_engine for execution. The only mild friction is the two overlapping entity layers (skills vs. engines) — get_skill mentions running an engine while describe_engine shows the engine schema — but the verb distinguishes intent clearly enough.
All five tools follow a strict verb_noun snake_case pattern (run_engine, search_skills, get_skill, list_engines, describe_engine). The convention is applied uniformly with no deviations in casing or style.
Five tools is well-scoped for a server exposing two related entity types: discovery (list_engines, search_skills), detail (get_skill, describe_engine), and execution (run_engine). No tool feels redundant, and none is missing at this granularity.
The lifecycle is largely covered: find skills, inspect a skill, list/describe/run engines. Minor gaps exist — no plain 'list all skills' without a problem query, and no batch or multi-engine run — but these are workable around since skills are discoverable via search_skills.
116 marketing, RevOps and SaaS calculators with benchmarks, guided reviews, content search, booking.
Deterministic what-if & scenario simulation for AI agents: projections, sensitivity & break-even.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Find and run exact business, finance and SaaS calculators instead of guessing the math.
