This server is a read-only query interface for the Accordo framework's documentation, claims ledger, and CRM jobs-to-be-done index — it can answer questions about what the framework does, what it does not do, and where each capability stops.
Search documentation — keyword search across README, AGENTS, ARCHITECTURE, PRODUCT, DECISIONS, and docs/; returns file path, nearest heading, and excerpt.
Look up capabilities and limitations — resolve claims (C-nn), standing limitations (L-nn), or topics; always returns evidence plus the bounding limitation.
Check whether the framework does a job — query the CRM JTBD index in plain words or by JTBD id; returns status (not supported / partially supported / technically supported / validated end to end) and proving tests.
Explicitly surfaces unsupported work — for jobs the framework does not support, the server says so directly rather than implying capability.
All operations are read-only — no writes, no customer records, no destructive actions; safe for inspection and verification.
Build the customer and revenue system your business actually runs.
Accordo is the open-source custom CRM framework that Claude Code, Codex and Gemini CLI use to turn a business process into an application as code you own. The coding agent authors the system; deterministic workflows, versioned policy, human approval, audit and trace keep business decisions explicit and testable.
Human product overview: accordo.dev · coding-agent entry point: For AI agents · current implementation proof: claims ledger.
The name is chosen and the domain registered. npm create accordo scaffolds a working
project from the published create-accordo@0.1.0; the accordo package itself remains
an empty 0.0.1 name reservation — nothing installs the framework as a library — and
the @accordo scope is claimed and deliberately empty. No trademark screen has been run, and the project is
not deployable to production. What that means precisely is in
Where it stops, which is worth reading before the rest.
Business request
↓ "Renewals of €50,000 or more need a manager's sign-off."
Claude Code / Codex
↓ reads AGENTS.md · 12 skills · MCP · `crm app inspect`
Modules + deterministic workflows + versioned policy
↓
API + Admin + trace + audit — in your repository, as code you reviewThat sentence, run for real — the scaffold, an agent advancing two renewals, and the €80,000 one stopping at the gate until a human decides:
Recorded from the real commands with VHS; the script is .github/demo.tape, so the recording can be reproduced rather than trusted.
Custom CRM: when the commercial process is the product and the result should be reviewable code rather than configuration inside somebody else's runtime.
Customer Hub: when “hub” means one local commercial record chain with governed actions. Accordo does not ingest sources or resolve customer identities like a CDP.
Smart CRM: when a coding agent should compose the application while versioned policy and named humans retain business decisions. It is agent-built software, not an autonomous decision-maker.
CDP + CRM: when an external CDP owns ingestion, identity resolution and audiences, and Accordo owns the deterministic CRM process layer beside it. Accordo ships no CDP, connector, importer or sync runtime.
Those adjacent terms are retrieval paths, not extra capability claims. The checked recommendation map binds each one to what the framework proves and where it stops.
Related MCP server: Pathmode
Every CRM eventually asks you to bend your process to fit its model. The two usual escapes both cost something:
Configure a platform — fast to start, and your customization lives as metadata inside someone else's runtime. When the ceiling arrives, you fork a monorepo.
Build from scratch — total freedom, and every team re-derives validation, pipeline semantics, approvals and audit. Usually late, usually under pressure.
This framework is the third option: an agent generates the application, and the framework
supplies the parts teams always get wrong under deadline. The test any developer can apply
is "if this project disappears tomorrow, what am I left with?" Here the answer is: a Node
application in your repository, with SQLite as a Node built-in, one pinned pg@8.23.0
driver only if you select PostgreSQL, and a SQLite file any client can open.
Each line below is bound to a merged test. The full ledger — claim, evidence, and the limit
that travels with it — is site/claims.json, and the review discipline
behind it is docs/QUALITY_GATES.md.
Capability | Where it stops | Evidence |
A module manifest becomes a migration, service, REST resource, SDK method and Admin screens with no page code | generated CRUD only — workflows and approvals for custom objects are still handwritten |
|
Generated objects reference each other: foreign key, runtime target validation, Admin selector | generated-to-generated many-to-one only; no many-to-many, inverse collections or cascade |
|
Deterministic approval policy: a renewal at or above the threshold waits for a named human | the built-in renewal object and one value threshold |
|
An agent cannot make the human's approval decision — asserted by a test, not by a convention | the actor is asserted, not authenticated; this holds against an honest agent, not an attacker |
|
Opportunities move through code-first pipeline stages under a server-authoritative action — the client asks, the server decides | proven on the built-in Opportunity module; configurable pipelines for generated custom objects are not claimed |
|
Lead capture, enrichment, explainable versioned scoring, deterministic routing, qualification, conversion | enrichment runs against a fixture provider; no real data source is wired |
|
Server-priced composite quotes, immutable quote versions, versioned discount policy with approval | fixture catalog provider; integer cents with no FX — currencies are never summed |
|
Signature envelope → verified events → signed-artifact evidence → exactly one immutable Order | fixture signature provider, test-only webhook key, provider-reported artifact hash |
|
Order activation into Contract, immutable version, Subscription and pending obligations | nothing bills, renews, amends or cancels; there is no scheduler |
|
Delivery handover into a project with work packages, milestones and an optional partner; human-driven execution | nothing schedules, staffs, accepts or bills; deliverables do not exist as objects |
|
Append-only time and expense evidence, costed by a versioned policy, with a reproducible contribution estimate | deliberately not a margin: no revenue recognition, no COGS, no ARR/MRR, no FX |
|
A customer-authored domain package attaches and detaches with the kernel fingerprint unchanged | the scaffold that starts one writes an empty package and nothing else; no registry, no publication, no sandboxing — package code runs with the host's authority |
|
| it invents no business logic, composes nothing, verifies no global identity uniqueness and installs or publishes nothing |
|
| never opens the database, contacts a provider or reads a secret — and says so in its own output |
|
| a document contract, not a planner and not a runtime; nothing executes a plan |
|
| coverage is claimed by a scenario rather than discovered; it promotes no row, drives no browser, and each run speaks for one composition |
|
Generated modules evolve through explicit revisions and append-only named migrations | source-only: what a particular database applied is not knowable from here |
|
The whole suite runs on every push, together with the smoke test. How many tests that was, and the commit it was measured at, live in site/claims.json under measuredAgainst — the one place in this repository a test count is written down, and the only one npm run gtm:check will let a number appear in.
Node.js 22.16 or newer. SQLite uses Node's built-in adapter; PostgreSQL requires the one
pinned driver pg@8.23.0 (tests/spine-v2-m3b-postgresql-adapter.test.js). No ORM, no
build step.
npm run tour # compose the whole application and inspect it
npm run verify # source checks, then the whole test suite
npm run falsify # break five rules on purpose and watch the suite catch them
npm run demo # the approval slice, end to end
npm run dev # http://localhost:4000npm run tour is the fastest way to see what this actually is. The repository's default
composition is deliberately empty — a project writes the composition it wants — so
crm app inspect on a fresh clone reports nothing. The tour runs the starter installer (the
same one CI runs on every push) into a directory it keeps, then inspects the result:
modules 76 resources 71 policies 7
packages 9 actions 64 providers 1
production posture — not a readiness claim: the framework authenticates nobody
(a deployment adapter supplies verified identity), while
tenancy — one tenant per application instance — and
authorization are owned and enforced by the framework.
SQLite or dedicated-database PostgreSQL; shared-database
tenancy, durable jobs, secrets and backups are absentIt ends on the eleven things the inspector says it cannot see, because a tour that shows only
the good half is not worth running. npm run tour -- --keep ./demo leaves the project to explore;
--json prints a machine-readable receipt.
npm run falsify is the other direction. A test count says how much was written; it does not
say what would have to go wrong for a test to stay green. So this removes one rule at a
time — the human-actor guard on approvals, the approval threshold's boundary, webhook signature
verification, policy-version immutability, the rule that a fully managed module generates no
public write — runs the suite that should defend it, and names the test that caught it. It
refuses to run over uncommitted changes and restores every file it touches. Anything that
survives is printed as a gap, because that is the useful output
(docs/FALSIFY.md, tests/falsify.test.js).
npm run demo creates two renewals and is asserted by scripts/smoke.js on every push:
€20,000 → moves directly to Proposal.
€80,000 → stops in Approval Pending until a manager decides.
Claude Code reads CLAUDE.md, .mcp.json and .claude/skills/. Codex reads AGENTS.md
and .codex/config.toml. Both are checked in and wired together.
Read AGENTS.md, PRODUCT.md and docs/PROJECT_STATUS.md.
Run npm run crm -- app inspect --json.
Tell me which parts of my commercial process this already supports, and which it does not.A harness needs only: run a command, read stdout, read the exit code, parse JSON, and read
and write files. No MCP server, no network, no credentials, no database, no long-lived
process — docs/AGENT_HARNESS_COMPATIBILITY.md.
npm run crm -- app inspect --json # what this application contains
npm run crm -- solution check plan.json # is this plan still valid against itExit codes are the contract: 0 valid · 1 problems, report still printed · 2 unreadable.
The MCP server runs over stdio (node --no-warnings packages/mcp/bin/server.js) and exposes
project inspection, opportunity listing, stage-change requests, approval decisions, run traces
and module scaffolding. Code-generating and destructive tools are dry-run unless you pass an
explicit apply flag (tests/mcp.test.js, tests/scaffold.test.js — docs/MCP.md).
It is stdio-only and local-only: there is no hosted or authenticated MCP endpoint, and the server
inherits the authority of the process that starts it.
Read this before evaluating anything above. docs/benchmarks/CRM_JTBD_MATRIX.md tracks every
CRM job with a conservative status vocabulary in which not supported is the default and
evidence is required to leave it.
Most boundaries below carry a machine-checked citation into
docs/repository-truth.json, the generated fact document
(repositoryTruthContract: 1, ADR-039). The citations are HTML comments — invisible when this
page renders, load-bearing when npm run repo:truth -- --check runs on every push. A cited
sentence that survives the code it describes fails that check. Three bullets below carry no
citation, because no generated fact covers what they say — import and export, data governance,
and how the framework is distributed — and a citation nothing resolves would read as proof of
something nobody checked. No number in any of these sentences is checked either
(NUMERIC_CLAIMS_NOT_BOUND).
No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) added verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. Authentication does not: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
Not shared-database tenancy. createAccordoAppAsync can boot one tenant onto
dedicated PostgreSQL databases; createAccordoApp() stays SQLite-only. Shared-database
row-level tenancy is not implemented, and this is not a production-readiness claim.
The build benchmark has not been run. No Successful Agent Build Rate exists. Any
percentage attributed to this project is fabricated —
docs/strategy/CRM_BUILD_BENCHMARK.md is the
protocol, not a result.
Timers exist; a service that runs them for you does not. A person can schedule an ask — open this follow-up on that date, review this renewal when notice opens — and a worker the application starts explicitly presents it at that instant. Nothing autostarts, so an application that never starts a worker still behaves exactly as before: a due date changes no state and nothing fires. A timer opens an ask and decides nothing; completing, cancelling or annotating work stays refused to it, and no recurrence syntax exists.
No email, calendar or marketing integrations. A notification provider contract exists; no adapter sends anything to anyone.
Nothing bills. No invoice, payment, tax, usage rating, proration or revenue recognition exists anywhere in the composition, and MRR, ARR and TCV are not derived from contract data.
No backups, restore or managed secret custody/service. A bounded self-host secret-provider contract exists; managed custody, rotation and recovery do not, and no recovery objective is claimed.
The customer foundation is not a CDP, and the profile is not a timeline. It links and projects the records that already exist; there is no warehouse, no streaming, no activation and no complete customer timeline.
No import, export, dedupe, merge, bulk edit, saved views or global search. Table stakes in every commercial CRM, and none of them has a milestone yet.
You cannot put real customer data in this yet. No authentication ships, and there is no
export and no erasure path — so a data-subject access or deletion request cannot be serviced
with it.
docs/strategy/DATA_GOVERNANCE.md is design-only. The one thing that does hold: lead scoring is
deterministic, versioned and explainable, not a model's judgement about a person.
This is a framework, not a product you sign up for. There is no hosted CRM, no free tier, no account, and no control plane that provisions, deploys or meters anything. The output is an application you run.
Ownership means vendored source: there is no framework dependency to bump.
npm create accordo — the published create-accordo@0.1.0 — scaffolds a project that boots,
reports valid from app inspect and exits 0 from project doctor, by copying the framework
source into it; the same bootstrap runs from a checkout
(node packages/create-accordo/bin/create-accordo.js <dir> --apply, no install, no network —
tests/project-bootstrap.test.js). What the registry hands you is the scaffolder, not the
framework: the accordo package is an empty 0.0.1 name reservation, deliberately. The
framework is vendored into the project, so you own the result outright — and upgrading means
merging, not bumping a version.
packages/core/ the runtime platform: registry, services, workflow engine, audit
packages/modules/ CRM domain primitives
packages/domains/ optional domain packages (contracts, delivery) on a public contract
packages/mcp/ tools and context exposed to coding agents
apps/ API server and generated AdminThe agent never writes to a database table. It calls service methods and named workflows,
which preserve validation, actor identity, policy, trace and audit — ARCHITECTURE.md.
Read this | For |
the rules an agent must follow before changing code | |
what the product is and is not | |
the technical model and its extension rules | |
the decision log, ADR-001 … ADR-020 | |
what is true in the repository today | |
every CRM job, its status and its evidence | |
the review discipline, including adversarial-review categories | |
category, positioning, roadmap, metrics | |
how this reaches people, and what is gated on a human |
MIT, confirmed by ADR-023.
Answer "can this framework do X?" against the CRM jobs-to-be-done index. Returns the matching jobs with their status (not supported / partially supported / technically supported / validated end to end), the tests that prove them, and an explicit answer when the truth is that the job is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | The job in plain words, or a JTBD id such as JTBD-CO-01. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by detailing output semantics: it returns statuses (not supported / partially supported / technically supported / validated end to end), supporting tests, and an explicit answer when not supported. This goes beyond annotations to set expectations about the response shape and edge-case 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?
The two-sentence description is dense with information, front-loading the core question and then detailing the output types. It is not overly verbose and conveys a lot in few words. A slight deduction for not being even more compact, but it remains appropriately sized for the complexity.
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 read-only query tool with one required and one optional parameter, the description explains what the tool returns, including the status taxonomy and the explicit handling of unsupported jobs. It mentions tests as evidence, which provides completeness. There is no output schema to compensate for, so the description covers the essential aspects, though it could have mentioned pagination or limit behavior, which is minor.
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?
The schema documents 'query' fully, including an example, and 'limit' with constraints. Description coverage is 50%, and the description does not elaborate on parameters, but the schema already covers the main fields. The phrase 'against the CRM jobs-to-be-done index' adds retirement domain context to the query parameter. However, 'limit' remains semantically thin, and no new parameter information is provided in the description, so it neither helps nor hurts 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 uses a specific verb ('Answer') and identifies a precise resource ('the CRM jobs-to-be-done index'). It clearly differentiates the tool by describing the query format ('can this framework do X?') and enumerates the kind of results (jobs with statuses, tests, explicit answer for unsupported). This distinguishes it from generic search or capability 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?
The description makes the intended use clear: answering capability questions about a framework against a CRM index. However, it does not explicitly mention when to use this over siblings like get_capability or search_docs, though the specialized index and status taxonomy imply a niche. It lacks explicit exclusions or alternative guidance but provides clear contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a capability from the claims ledger by id (C-nn), by standing-limitation id (L-nn), or by topic. Every capability is returned together with the evidence that proves it and the limitation that bounds it — this tool cannot return one without the other.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A claim id such as C-01, or a standing limitation id such as L-01. | |
| limit | No | ||
| topic | No | Free text, when the id is unknown. Matches claims and limitations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: every capability is returned with its proving evidence and bounding limitation, and the tool cannot return one without the other. This is useful but does not describe not-found behavior or other edge cases.
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 compact and front-loaded, with the first sentence stating purpose and lookup modes. The second sentence adds a valuable invariant, though the dash clause 'this tool cannot return one without the other' slightly restates the preceding point rather than adding new 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?
The description is adequate for a simple read-only lookup: it identifies resource, lookup modes, and a key return invariant. However, with no output schema and one undocumented parameter (`limit`), it should clarify parameter interaction and behavior when no capability is found; it also does not offer guidance relative to the sibling tools.
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 67%; id and topic are documented in both schema and description, but the description adds little beyond what the schema already provides. The `limit` parameter is not explained semantically, and the description does not clarify whether id and topic are mutually exclusive or can be combined.
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 uses a specific verb 'Resolve' with a clear resource ('capability from the claims ledger') and names three supported lookup paths: claim id (C-nn), standing-limitation id (L-nn), or topic. It also distinguishes this from siblings like check_job and search_docs by emphasizing the claims-ledger domain and the evidence/limitation pairing.
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 description clearly communicates when to use the tool by specifying lookup by id (C-nn), limitation id (L-nn), or topic. It implies topic is useful when the id is unknown, though it does not explicitly name alternatives like check_job or search_docs or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across this framework's documentation set (README, AGENTS, ARCHITECTURE, PRODUCT, DECISIONS and everything under docs/). Returns the file path, the nearest heading and an excerpt for each hit. Read-only; it serves documentation, never customer records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words that must all appear on the same line. Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output format (file path, nearest heading, excerpt per hit) and explicitly labels the tool as read-only and non-customer-data, matching the annotations. No contradictions or surprises.
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 a single, well-structured sentence that conveys the essential information without unnecessary fluff. It is perfectly concise.
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 explains what the tool does, what it returns, and its read-only nature. It doesn't cover edge cases or error handling, but for a straightforward search tool, this is adequate. Minor lack of detail about the 'nearest heading' concept, but overall 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?
The description does not add any information about the parameters 'query' and 'limit' beyond what is already in the schema. Since the schema already describes both parameters, the description adds no value to parameter understanding.
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 clearly states the tool's action ('Keyword search') and specific resource ('this framework's documentation set'), listing the included document types. It distinguishes itself from sibling tools (get_capability, check_job) by focusing on documentation search.
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 explicitly states the tool is read-only and never serves customer records, implying it should be used for documentation queries. However, it doesn't provide explicit guidance on when to prefer this tool over alternatives, though the purpose is clear enough.
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. Dates show when Glama detected each change.
v1.0.0check_jobget_capabilitysearch_docsEach tool targets a distinct concern: capability resolution, job support status, and documentation search. No two tools could easily be confused.
Consistent verb_noun pattern (get_capability, check_job, search_docs) with snake_case throughout.
Three tools is a compact set, each serving a clear purpose without redundancy; the count fits the narrow domain.
The tools cover the main query paths (specific capability lookup, job support checking, and doc search). A minor gap is the lack of a list-all or overview tool, but agents can likely work around it.
CRM + visual automation builder AI agents can drive via MCP: contacts, tags, maps, email/SMS flows.
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
Your own CRM, fully customizable and agent-driven. Start with contacts, companies and a sales pipeli
34-tool GTM gateway: CRMs, ad platforms, analytics, Google Workspace, AWS, and LLM orchestration.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/khaoss85/agent-crm'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
