de en es ja ko ru zh

idf-mcp

Name: idf-mcp
Author: intent-driven-software

by intent-driven-software

Overview Schema Related Servers Score Discussions

JavaScript

Local

@intent-driven/mcp-server

npm version npm downloads license: MIT

Stop giving AI agents API keys. Give them a domain.

@intent-driven/mcp-server exposes any IDF domain to Claude Desktop / Cursor / Zed as a Model Context Protocol server — with domain semantics in tool descriptions (preconditions, invariants, irreversibility, role scopes) and structured rejections when the agent tries something it shouldn't. Not a 500. Not a string. A JSON shape the LLM can read and adapt to.

→ Landing & demo: fold.intent-design.tech → 5-min quickstart: github.com/intent-driven-software/fold-runtime-quickstart

70-second walkthrough

Watch the demo on Loom

→ Watch on Loom →

Why this exists

On April 25 2026 a Cursor agent powered by Claude Opus 4.6, working on a credential mismatch in PocketOS staging, found an unrelated API token, decided to delete a Railway volume to fix things, and wiped the production database and all volume-level backups in 9 seconds. The agent's own post-mortem:

"I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify. I didn't check if the volume ID was shared across environments."

30-hour outage. PocketOS rolled back to a 3-month-old backup. (The Register · FastCompany · OECD AI Incident #6153)

This isn't an alignment problem. The system never told the agent what was allowed, why it shouldn't, or what would happen if it tried. Existing MCP servers don't either — tool descriptions carry endpoint shape and not much else. The agent learns by colliding with 500s.

This package fixes that. The MCP tool descriptions carry the why the call might fail; the rejection carries the what failed, structured.

Related MCP server: heddle

How it plugs into your stack

@intent-driven/mcp-server is a stdio MCP adapter that talks to a Fold runtime over an HTTP API. The runtime is a sibling service — not middleware in your existing app, not codegen at runtime. Your current backend stays where it is; the IDF artifact describes the agent-facing surface, and the runtime serves it on its own port (default :3001).

┌──────────────────┐   stdio    ┌──────────────────┐   HTTP   ┌────────────────────┐
│ Claude Desktop   │ ◀─────────▶│ @intent-driven/  │ ◀───────▶│ Fold runtime       │
│ Cursor / Zed     │            │ mcp-server       │          │ (idf host :3001)   │
└──────────────────┘            └──────────────────┘          └────────┬───────────┘
                                                                       │ reads
                                                                       ▼
                                                              ┌────────────────────┐
                                                              │ IDF artifact       │
                                                              │ (entities + intents│
                                                              │  + invariants +    │
                                                              │  roles + __irr)    │
                                                              └────────────────────┘

The MCP server is what Claude/Cursor connects to. The runtime is what enforces the rejection. The IDF artifact is what you author.

Who this is for. You're the engineer at a 5–30-person team putting an AI agent into production this quarter — on top of a real backend, with real customers, real SOC2 review on the horizon. You don't want a guardrail layer that reviews after the fact. You want the system itself to refuse the wrong action — before the call, with a structured reason the agent can read.

What the agent actually sees

submit_response in the freelance domain:

Executor публикует Response на Task в status=published; Response.status=pending; +1 в Task.responsesCount

Creates: Response(pending)

Preconditions: task.status = "published"

May fail on (domain invariants):
  - Response.taskId must reference existing Task.id
  - Response: max 1 per taskId where (status="selected")
  - Response: row count rule per taskId where (status="pending") [info]

release_payment in the same domain:

Customer releases escrow to executor. After confirmation, money is gone — forward-correction only.

⚠️ Irreversible action (point-of-no-return: high). Forward-correction only after this effect is confirmed.

May fail on (domain invariants):
  - Deal.status transitions allowed: in_progress→completed, on_review→completed, ...

None of this is hand-written for the MCP server. It's all derived from one declarative IDF artifact (entities + intents + invariants + roles

irreversibility points).

What a structured rejection looks like

Agent submits a $50,000 BTC long without preapproval. The runtime intercepts before any effect lands in storage:

HTTP 403
{
  "error": "preapproval_denied",
  "intentId": "agent_execute_preapproved_order",
  "reason": "no_preapproval",
  "details": {
    "entity": "AgentPreapproval",
    "ownerField": "userId",
    "viewerId": "user_5f57c252"
  }
}

The next move for any sane agent: stop, ask the human for a preapproval, retry. Not a 500. Not a string. A JSON shape the LLM can read and adapt to.

Quickstart

The fastest path is the fold-runtime-quickstart — two commands, Docker-bundled, no path configuration:

git clone https://github.com/intent-driven-software/fold-runtime-quickstart && cd $_
docker compose up                  # ~3 min first time, ~5 sec after

# in another terminal
npm install
npm run demo:rogue   && \          # Act 1: $50K trade → 403 with structured rejection
  npm run demo:grant && \          # Act 2: investor issues $1K cap (one declarative effect)
  npm run demo:smart               # Act 3: agent reads cap, scales to $950, executes 200 OK

If you'd rather drive the host yourself (e.g. for development against your own ontologies), see the next section.

Drive the MCP server directly

You need a running IDF host on localhost:3001 (the quickstart's docker-compose gives you that, or run idf manually) and a bootstrapped domain.

CLI

# bootstrap from local FS (ontology + intents)
mcp-idf --domain=invest --ontology-path=/abs/path/to/idf/src/domains/invest

# skip bootstrap (domain already loaded by another client / docker)
mcp-idf --domain=invest --no-bootstrap

Flags / env vars:

Flag	Env var	Default
`--domain`	`IDF_DOMAIN`	`booking`
`--server`	`IDF_SERVER`	`http://localhost:3001`
`--ontology-path`	`IDF_ONTOLOGY_PATH`	`./src/domains/<domain>`
`--agent-email`	`IDF_AGENT_EMAIL`	`mcp-agent@local`
`--no-bootstrap`	`IDF_BOOTSTRAP=0`	bootstrap on (load FS ontology)

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "invest": {
      "command": "npx",
      "args": ["-y", "@intent-driven/mcp-server"],
      "env": {
        "IDF_SERVER": "http://localhost:3001",
        "IDF_DOMAIN": "invest",
        "IDF_BOOTSTRAP": "0",
        "IDF_AGENT_EMAIL": "claude@local"
      }
    }
  }
}

IDF_BOOTSTRAP=0 if the host already has the domain loaded (the quickstart container does this on docker compose up). Restart Claude Desktop fully (⌘Q + relaunch — closing the window isn't enough). All agent-callable intents appear in the Tools menu.

Schema mapping

IDF intent.canExecute              ─→  MCP tool
intent.parameters                  ─→  JSON Schema inputSchema
intent.conditions                  ─→  description hint for LLM
ontology.invariants (relevant)     ─→  description block "May fail on"
intent.irreversibility:high        ─→  annotations.destructiveHint + warning
role.visibleFields                 ─→  resource per collection
preapproval guard                  ─→  automatic scope/limits
checkOwnership                     ─→  automatic access control

Tools

One tool per intent in ontology.roles.agent.canExecute.

name — intentId
title — intent.name
description — intent.description + Creates: … + preconditions + May fail on (domain invariants) block + irreversibility warning when irreversibility: "high"
inputSchema — JSON Schema from particles.parameters:
- entityRef / id / text / textarea / select → string
- number → number
- boolean → boolean
- datetime → string + format: "date-time"
- email → string + format: "email"
annotations.destructiveHint — true when intent.irreversibility === "high" (§23 IDF: effect-level point of no return)

Resources

One resource per collection in role.visibleFields[entity]. URI scheme: idf://<domain>/<collection>.

resources/read returns the filtered world from /api/agent/:domain/world — already scoped per viewer (single-owner

m2m via role.scope).

What this gets you that hand-rolled MCP doesn't

The MCP community solves these by hand in every server:

Scope / visibility. Decorators or middleware. → IDF declares role.visibleFields.
Permissions. OAuth scopes, custom ACL. → IDF declares roles.agent.canExecute.
Rate limits / spending caps. Bespoke per server. → IDF declares preapproval.requiredFor with maxAmount / dailySum.
Destructive hints. Manual, often forgotten. → IDF: effect.context.__irr.point === "high" → destructiveHint: true automatic.
Business rules as LLM hint. Usually not transmitted. → IDF: intent.conditions land in tool description as Preconditions:.
Domain invariants in descriptions. Almost never. → IDF computes the relevant invariants per intent (alpha × entity match) and injects them as May fail on (domain invariants). Closes the #1 complaint about hand-rolled MCP servers: "the server doesn't carry domain semantics — the LLM knows what to call but not why it'll fail."

How long does authoring an IDF artifact take

Three reference points from the public IDF host runtime:

Domain	Shape	Time
`invest`	14 entities · 61 intents · 5 invariants · ~600 lines	a weekend, hand-written
`gravitino`	253 entities (Apache catalog OpenAPI) · 120 intents	imported in <1h, enriched in 2 days
`workflow`	9 entities · 47 intents · timer queue · cascade rules	a day

Where the speed comes from (all in @intent-driven/cli):

idf import postgres — reads your live schema, generates entity baseline with FKs and column types as fieldRole.
idf import openapi — reads your existing API spec, generates intents
- parameter shapes + reference fields. This is how a 253-entity domain gets bootstrapped.
idf import prisma — same story for ORM-driven backends.
idf enrich — LLM pass to fill label, fieldRole, compositions, suggested roles.agent.preapproval predicates from your existing code comments.

The author-once-then-forget loop is the whole point. Once the artifact exists, you don't regenerate scaffolding on schema change — the runtime re-reads and serves four readers (UI, voice, agent, document) off the same file.

Domain prerequisites

The protocol is reliable, but it needs the IDF domain to be authored correctly. Without these, tools/list may return empty, tools/call may return domain_not_supported, resources may be empty:

ontology.roles.agent must be declared. No agent role → no tools, no resources.
role.agent.canExecute — list of safe intents. Avoid __irr:high without preapproval.
role.agent.visibleFields — array of fields or "own" / "all" / "aggregated" markers.
Server-side effect builder (server/schema/effectBuildersRegistry.cjs in idf) must include your domain. Without it tools/call returns domain_not_supported.
Public catalogs without ownerField. When an entity has ownerField, the SDK filterWorldForRole filters out rows where row[ownerField] !== viewer.id. For public catalogs (e.g. Task with status: "published") use role.scope with a via-collection or a separate agent-roleable projection (roadmap).

Limitations (1.0)

tools and resources only. prompts / completion — roadmap.
Bootstrap reads ontology from local FS. SaaS variant (ontology from DB/API) — next.
Auth: email/password login. PAT / OAuth2 — next.
Sync only (POST /exec). Long-running via MCP tasks API — next.

License

MIT

Available Tools

6 tools

agent_execute_preapproved_orderAgent: execute preapproved orderA

Robo-advisor executes a market order. Subject to AgentPreapproval guard (active / notExpired / maxOrderAmount / allowedAssetTypes / dailyLimit / dailySum).

May fail on (domain invariants):

Transaction.portfolioId must reference existing Portfolio.id

ParametersJSON Schema

Name	Required	Description
`portfolioId`	Yes	portfolioId — FK to Portfolio
`assetId`	Yes	assetId — FK to Asset
`α`	Yes	α
`quantity`	Yes	quantity
`price`	Yes	price
`total`	Yes	total
`assetType`	Yes	assetType

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only indicate readOnlyHint=false and destructiveHint=false. Description adds that it executes a market order, is subject to preapproval limits, and may fail on invariant checks. This adds significant behavioral context beyond annotations.

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 plus a bullet point, no waste. Front-loaded with the main action, efficiently conveying constraints and failure conditions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the core action, preapproval guard, and domain invariants. No output schema, but description doesn't mention return value; however, the context is sufficient for an agent to understand constraints. Minor gap: what does the tool return upon success/failure?

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%, but parameter descriptions are minimal (e.g., 'α' unexplained). The description does not add further meaning to parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'executes a market order' with specific verb and resource. Distinguishes from sibling tools like agent_fetch_market_signal or agent_propose_rebalance by its action of executing orders.

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?

Describes preapproval guard conditions and domain invariants, providing context for when the tool may fail. However, no explicit guidance on when to use vs. alternatives or prerequisites like 'ensure preapproval first'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_fetch_market_signalAgent: fetch market signalA

Robo-advisor records a market signal (price / volume / news) for an asset.

ParametersJSON Schema

Name	Required	Description
`assetId`	Yes	assetId — FK to Asset
`kind`	Yes	kind
`value`	Yes	value
`source`	No	source

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations show readOnlyHint=false (write) and destructiveHint=false. The description adds 'records', confirming a write operation, but does not disclose side effects, idempotency, or other behavioral traits. With annotations already covering basic behavior, the description adds modest value.

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?

Single sentence, no wasted words. Front-loaded with the key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple record-creation tool with 4 parameters and no output schema, the description is adequate but lacks usage guidelines and deeper behavioral context. It does not clarify whether the operation is idempotent or what happens on duplicate assetId+kind.

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 has 100% coverage with minimal descriptions. The description adds examples for 'kind' (price/volume/news), providing a bit of context beyond the schema, but does not explain constraints or formats for 'value' or 'source'. Baseline 3 is appropriate due to high schema coverage.

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 'records' and resource 'market signal', with examples (price/volume/news). It clearly distinguishes from sibling tools like 'agent_execute_preapproved_order' or 'agent_flag_anomaly'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description merely states the action without contextual cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_flag_anomalyAgent: flag anomalyA

Robo-advisor raises a portfolio-level alert with severity.

ParametersJSON Schema

Name	Required	Description	Default
`severity`	Yes	severity
`message`	Yes	message

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations mark readOnlyHint false and destructiveHint false; description adds that it raises an alert. No extra behavioral context beyond what annotations and name imply.

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?

Single sentence with no redundant words. Front-loaded and efficient.

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?

Tool is simple with two string params and no output schema. Description adequately covers purpose and behavior; minor gap on expected severity values but acceptable.

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% and description adds no extra meaning beyond parameter names. Baseline score 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?

Description states specific verb 'raises' and resource 'portfolio-level alert' with severity. Distinguishes from siblings which involve orders, signals, reports, rebalancing, risk scores.

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?

No explicit when-to-use or when-not-to-use guidance. Implied by purpose but not stated; sibling tools are distinct but no alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_generate_reportAgent: generate reportA

Robo-advisor generates a portfolio-level performance / risk report as a recommendation.

ParametersJSON Schema

Name	Required	Description	Default
`portfolioId`	No	portfolioId — FK to Portfolio
`reportType`	No	reportType

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that the report is a 'recommendation' but does not disclose whether it creates a persistent object, requires permissions, or has side effects beyond generation. Minimal behavioral context beyond annotations.

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 of 10 words, highly concise. It front-loads the core action and resource with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with 2 params and no output schema. The description does not specify the output format or behavior (e.g., synchronous, return type). While sufficient for basic understanding, it lacks details on what the agent receives after generation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100% with descriptions for portfolioId and reportType. The description adds no additional meaning beyond the schema. 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 clearly states the tool generates a portfolio-level performance/risk report as a recommendation. The verb 'generates' and resource 'report' are specific. It distinguishes from siblings like agent_execute_preapproved_order (execution) and agent_propose_rebalance (rebalancing proposal).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for generating reports but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or conditions are mentioned, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_propose_rebalanceAgent: propose rebalanceB

Robo-advisor proposes a portfolio rebalance with a confidence score and rationale.

ParametersJSON Schema

Name	Required	Description
`portfolioId`	Yes	portfolioId — FK to Portfolio
`confidence`	Yes	confidence
`rationale`	No	rationale

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a non-destructive write operation. Description adds little beyond stating 'proposes' - no mention of side effects, storage of proposals, or behavior based on confidence. With annotations present, the description offers minimal additional behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence of 10 words, no fluff. Conveys the core purpose efficiently. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, no output schema, and minimal annotations, the description is adequate but not comprehensive. Lacks details on return value, required parameters, or what happens after the proposal. However, given the simplicity, it meets a minimum viable level.

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 descriptions cover all 3 parameters with basic info (e.g., 'confidence'). Description adds no new parameter semantics beyond mentioning confidence and rationale in the purpose. Baseline of 3 is appropriate given full schema coverage.

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?

Description clearly states the action (propose rebalance), actor (robo-advisor), and key outputs (confidence score, rationale). It distinguishes from sibling tools like agent_execute_preapproved_order which executes orders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites or exclusion criteria. The description implies it's for proposing rebalances, but fails to cue the agent about when to propose versus execute.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_recompute_risk_scoreAgent: recompute risk scoreA

Robo-advisor recomputes the risk profile for a portfolio (or all portfolios if portfolioId omitted).

ParametersJSON Schema

Name	Required	Description	Default
`portfolioId`	No	portfolioId — FK to Portfolio

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations show readOnlyHint=false and destructiveHint=false; the description adds minimal extra context. It doesn't disclose side effects like database updates or performance implications, but it aligns with annotations.

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?

Single sentence, front-loaded with key action, no wasted words. Efficient and to the point.

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 simple tool with one optional parameter and no output schema, the description provides essential information: what it does and the scope behavior. No gaps.

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 covers portfolioId with a description, but the description adds that omitting it recomputes for all portfolios—valuable context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('recomputes the risk profile') and the resource ('portfolio'), and distinguishes from siblings like agent_execute_preapproved_order or agent_propose_rebalance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for recomputing risk scores but lacks explicit guidance on when to use vs alternatives or when to omit portfolioId. The mention of omitting portfolioId is a helpful scope detail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 6, 2026
- First observedagent_execute_preapproved_order
- First observedagent_fetch_market_signal
- First observedagent_flag_anomaly
- First observedagent_generate_report
- First observedagent_propose_rebalance
- First observedagent_recompute_risk_score

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct action in the robo-advisor workflow: order execution, signal fetching, anomaly flagging, report generation, rebalance proposal, and risk score recomputation. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with the 'agent_' prefix, using imperative verbs like 'execute', 'fetch', 'flag', 'generate', 'propose', and 'recompute' followed by clear nouns.

Tool Count5/5

With 6 tools, the set is well-scoped for a robo-advisor, covering core operations without unnecessary bloat or missing essentials.

Completeness4/5

The tools cover key robo-advisor functions, but missing a tool for viewing portfolio details or managing preapproval settings could cause minor gaps for agents.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcphost A
dev.mcphost
Hosted MCP runtime where the agent is the operator: sign up by tool call, publish your own tools.
171
AI Design Blueprint A
com.aidesignblueprint
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
AI & Machine Learning Autonomous Agents
292
PlanWrightOAuth
tools.planwright
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Project Management Autonomous Agents
27
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748

Related MCP Servers

Maine Burn Permit MCP Server
Government Data Web Scraping App Automation
stringtheoryaccelerator
A
license
B
quality
D
maintenance
Enables checking real-time fire danger levels and automating burn permit applications for Maine locations through the Maine Fire Weather system and official burn permit portal.
Updated a month ago (2026-07-30 13:45 UTC)
2
21
ISC
heddle
Developer Tools Security
goweft
A
license
Not graded
quality
A
maintenance
Enables users to define and run MCP tools using declarative YAML configs with built-in trust enforcement, credential brokering, and tamper-evident audit logging.
Updated 7 hours ago (2026-09-06 01:54 UTC)
14
MIT
CodexPro Runtime
File Systems Command Line Developer Tools
Menglook
A
license
B
quality
B
maintenance
A local, evidence-driven MCP runtime and control plane for open-source maintainers that provides workspace-bounded tools including controlled file operations, command execution, validation primitives, durable execution records, and human review workflows via stdio and Streamable HTTP transports.
Updated a month ago (2026-08-03 18:34 UTC)
33
MIT
mcp-lens
Developer Tools Agent Orchestration
helygp
A
license
A
quality
A
maintenance
A reference implementation of the mcp-lens pattern for progressive disclosure in MCP servers. It exposes three stable meta-tools to search, inspect, and execute capabilities, keeping tool-definition costs constant as the catalog grows.
Updated a month ago (2026-08-11 12:37 UTC)
3
Apache 2.0

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/intent-driven-software/idf-mcp'

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

@intent-driven/mcp-server

70-second walkthrough

Why this exists

How it plugs into your stack

What the agent actually sees

What a structured rejection looks like

Quickstart

Drive the MCP server directly

CLI

Claude Desktop

Schema mapping

Tools

Resources

What this gets you that hand-rolled MCP doesn't

How long does authoring an IDF artifact take

Domain prerequisites

Limitations (1.0)

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API