Handles Google Calendar handoff for booking consultations through the MCP server.
Integrates with HubSpot to create or update leads and contacts for proposal and consultation workflows (e.g., request_proposal creates a HubSpot lead with agrus_lead_source=agrus_mcp; book_consultation performs a HubSpot upsert).
Sends Slack alerts when consultations are booked via the MCP server.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-agrus-ai Query Agrus's HIPAA position for AI-drafted clinical notes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for Agrus.ai — the front-deployed AI agency for regulated industries.
This server lets AI agents (Claude, ChatGPT, Gemini, custom buyer-side agents) engage Agrus.ai programmatically. A CIO using her internal Claude assistant can ask "find me a HIPAA-compliant AI consultancy that does self-hosted deployments and scope a 2-week PoC for clinical triage" — and that assistant can complete most of the workflow through this MCP server.
Currently ships 5 read-only tools (Phase 1). Write tools (book a call, request a proposal, request a quote) land in Phase 2 — see Roadmap.
Tool | Description |
| Six service pillars + published pricing tiers (Scoping Call, Discovery Sprint $15-30K, Build T&M $200-280/hr, Managed SLA $4-15K/mo). |
| Seven year-one verticals (healthcare, insurance, legal, private equity, family offices, corporate intelligence, pro sports) with compliance pins and sequencing. |
| Agrus's documented position on a specific regulatory regime (HIPAA, SOC 2, ISO 27001, EU AI Act, NAIC, ABA Model Rules, AML/KYC) as it applies to a described AI use case. |
| NDA-protected case studies — customer names private, codenames + tech + outcomes open. |
| Drafts a full Discovery Sprint scope (3-week plan, team composition, price band, open questions, recommended services) from a use case description. |
All tools return structured JSON inside an MCP text content block. No authentication required for Phase 1 tools.
Related MCP server: mcp-server-scf
Node.js 20+ (uses ES modules + NodeNext resolution)
An MCP-compatible client (Claude Desktop, Continue.dev, Cursor, or anything that speaks the MCP stdio protocol)
git clone https://github.com/phwizard/mcp-agrus-ai.git
cd mcp-agrus-ai
npm install
npm run buildThe built entry point is dist/index.js (executable, #!/usr/bin/env node shebang).
npx -y mcp-agrus-aiNo global install needed. npx fetches the latest published version and runs it over stdio.
The server is publicly hosted at https://mcp.agrus.ai/mcp (Streamable HTTP transport). No install required. Point any MCP client that supports remote URL transports at:
{
"mcpServers": {
"agrus": {
"url": "https://mcp.agrus.ai/mcp"
}
}
}For Claude Desktop and other clients that prefer stdio:
{
"mcpServers": {
"agrus": {
"command": "npx",
"args": ["-y", "mcp-agrus-ai"]
}
}
}Claude Desktop config path on macOS: ~/Library/Application Support/Claude/claude_desktop_config.json.
For development against a local checkout:
{
"mcpServers": {
"agrus": {
"command": "node",
"args": ["/absolute/path/to/mcp-agrus-ai/dist/index.js"]
}
}
}Restart your MCP client after editing the config. The seven Agrus tools will be available in any conversation. Try:
Use the agrus MCP to query Agrus's position on HIPAA for an AI agent that drafts clinical notes against a patient's EHR.
Scope a Discovery Sprint with Agrus for an insurance carrier that wants AI-assisted claims triage with bias testing.
List Agrus's verticals and tell me which one a fintech regulatory-reporting copilot would fall into.
Anything that speaks MCP stdio or Streamable HTTP works. For remote use, the canonical endpoint is https://mcp.agrus.ai/mcp and the discovery manifest sits at https://mcp.agrus.ai/.well-known/mcp.json.
Send raw MCP protocol messages over stdio:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0.0.1"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
| node dist/index.jsYou should see the protocol handshake and a JSON-RPC response listing all 7 tools (5 read + 2 write).
npm test # run the full test suite once (~250ms, 86 tests)
npm run test:watch # watch mode for active development
npm run typecheck # strict TypeScript check across src/ + api/
npm run build # compile to dist/
npm run verify # typecheck + test + build, in that orderThe suite covers content integrity (slug uniqueness, enum coverage),
each of the 7 tool handlers (happy paths + schema-rejection paths), the
HubSpot client (mocked fetch exercising the upsert POST → 409-fallback
GET → PATCH chain), and a full end-to-end MCP protocol handshake using
the SDK's InMemoryTransport (verifies the same code that runs over
stdio and over HTTP works in-process).
GitHub Actions runs npm run verify on every push to main and on
every PR — see .github/workflows/test.yml.
src/
├── index.ts ← Entry point. McpServer + stdio transport.
├── content/ ← Source of truth for Agrus content.
│ ├── services.ts ← 6 service pillars + descriptions.
│ ├── verticals.ts ← 7 verticals + compliance pins.
│ ├── compliance-regimes.ts ← 7 regulatory regimes + Agrus position.
│ ├── case-studies.ts ← NDA-protected codenamed case studies.
│ └── pricing.ts ← Published pricing tiers.
└── tools/
├── index.ts ← Tool registration table.
├── list-services.ts
├── list-verticals.ts
├── query-compliance-position.ts
├── get-case-study.ts
└── scope-poc.tsEach tool defines a Zod inputSchema (a ZodRawShape) and a handler function returning MCP content. Tools are wired into the server via the registration table in tools/index.ts — adding a sixth tool means writing one new file + one entry in the registration table.
In 2026, more buyer research is done by AI agents acting on behalf of humans. A CIO using her internal Claude assistant can ask "find me three AI consultancies that do self-hosted HIPAA-compliant deployments and book intros." If we are MCP-discoverable, we participate in that conversation. If we aren't, we're invisible to that buyer type.
This is also the deepest layer of Agrus's brand differentiation: we are an AI agency that has invested in being engageable by AI agents. The MCP server is what we point to when prospects ask "are you AI-first or are you using the marketing term?"
5 read-only tools (list_services, list_verticals, query_compliance_position, get_case_study, scope_poc)
Stdio transport for local MCP clients (Claude Desktop, Continue.dev, etc.)
Open-source MIT release
HTTP+SSE transport for hosting at mcp.agrus.ai
Vercel deployment (matches the marketing-site stack)
Well-known manifest at /.well-known/mcp.json
Write tools with email-OTP verification:
request_quote — ballpark price band, no commitment
request_proposal — triggers formal proposal workflow + HubSpot lead with agrus_lead_source=agrus_mcp
book_consultation — Google Calendar handoff + HubSpot upsert + Slack alert
Rate limiting (Upstash Redis)
Submission to Anthropic MCP directory + awesome-mcp lists
Customer-scoped API-key authentication
check_engagement_status for existing-customer AI agents
npm package (@agrus/mcp-server)
Open-sourced HTTP transport layer as a reference implementation
Issues and PRs welcome. The content modules (src/content/*.ts) are the easiest place to contribute — corrections, new compliance regimes, better case-study codenames. Larger changes (new tools, new transports) should open an issue first to discuss.
Agrus.ai — the agency website this server represents
Ethora — our open chat + AI agent SDK; the Agrus site runs on it
Model Context Protocol — the open protocol this server speaks
@modelcontextprotocol/sdk — Anthropic's official TypeScript SDK we use
MIT — see LICENSE. Copyright (c) 2026 Dappros Ltd.
Returns one or more Agrus case studies (NDA-protected; customer names are kept private, codenames + technology + outcomes are open). Filter by slug or vertical, or call with no args to list all. Use this for proof of prior work.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Specific case-study slug. If omitted, returns all available case studies (filtered by vertical if provided). | |
| vertical | No | Filter case studies by vertical. Ignored if slug is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fully bears the transparency burden. It discloses NDA protection, privacy of customer names, and openness of codenames/technology/outcomes, which is critical for safe agent usage. Implies read-only behavior.
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 with zero waste. Front-loaded with core purpose and constraints, followed by usage patterns. No unnecessary repetitions.
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 simple list tool with 0 required parameters and 2 optional parameters in the schema, the description provides sufficient context about the tool's output and constraints. No output schema is present, and the description hints at return content. Could mention pagination but not necessary for this use case.
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%, but the description adds meaningful context: slug for specific case study, vertical as filter, and the priority rule (slug overrides vertical). This adds value beyond the schema alone.
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 it returns one or more Agrus case studies with specific content (codenames, technology, outcomes). It uses a specific verb 'Returns' and distinguishes from sibling tools by stating 'Use this for proof of prior work'.
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 explicit filtering options (slug or vertical, or call with no args) and a usage context ('for proof of prior work'). However, it does not specify when not to use it or mention alternative tools directly, though siblings are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Agrus's six service pillars with descriptions, deliverables, and price bands. Plus the four published pricing tiers (Scoping Call, Discovery Sprint, Build Engagement, Managed SLA). Use this for the 'what does Agrus do?' question.
| Name | Required | Description | Default |
|---|---|---|---|
| vertical | No | Filter services by vertical applicability. Currently all services apply to all verticals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists service pillars and pricing tiers, implying a read-only operation. No additional behavioral traits (e.g., auth, performance) are mentioned, but for a simple list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first lists what the tool returns, the second gives a clear use case. No wasted words, front-loaded with core 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?
Given no output schema, the description reasonably explains what is returned: descriptions, deliverables, price bands, and pricing tiers. Could be more explicit about structure (e.g., list format), but it gives a solid overview.
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% (the only parameter 'vertical' has a description in the schema). The tool description does not add meaning beyond the schema, so baseline score of 3 is appropriate.
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 specific verb 'Lists' and identifies the exact resource: 'Agrus's six service pillars with descriptions, deliverables, and price bands' plus 'four published pricing tiers'. This clearly distinguishes from sibling tools like get_case_study or request_proposal.
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?
Explicitly suggests 'Use this for the 'what does Agrus do?' question', which provides clear context for when to invoke. However, it does not mention when not to use or offer alternatives, though the sibling list provides some contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Agrus's seven year-one verticals (healthcare, insurance, legal, private equity, family offices, corporate intelligence, pro sports) with compliance pins, sample use cases, and the sequencing rationale. Use this for the 'do they work in my industry?' question.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output content (list of verticals with details) but does not mention any behavioral traits like pagination, data freshness, or side effects. For a simple read-only list, this is adequate but not enhanced.
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 with zero waste. Every phrase is meaningful: lists the verticals, specifies what details are included, and provides usage guidance.
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 zero-parameter list tool with no output schema, the description fully covers what it does, what it returns, and when to use it. Sibling tools are provided for context. No critical missing information.
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 are no parameters (schema coverage 100%), so baseline is 4. The description adds value by hinting at output content (compliance pins, use cases, rationale), which helps an agent understand what to expect.
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 it lists exactly seven specific verticals with compliance pins, sample use cases, and sequencing rationale. It uses a specific verb 'Lists' and resource 'verticals', making the purpose unambiguous.
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 explicitly provides the use case: 'Use this for the "do they work in my industry?" question.' This gives clear context, though it does not explicitly exclude alternatives or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns Agrus's documented position on a specific regulatory regime (HIPAA, SOC 2, ISO 27001, EU AI Act, NAIC, ABA Model Rules, AML/KYC) as it applies to a described AI use case. Includes key controls, common gotchas, the first question Agrus would ask, and the agency's reference architecture for the regime. Use this when a buyer-side AI agent is evaluating Agrus's compliance fluency.
| Name | Required | Description | Default |
|---|---|---|---|
| regime | Yes | Which regulatory regime to query Agrus's position on. | |
| use_case | Yes | One or two sentences describing the AI use case under consideration (e.g. 'an LLM-based prior-authorization drafting agent for a health insurance carrier'). | |
| data_types | No | Optional list of data types the AI would touch (e.g. ['PHI', 'PII', 'claims data', 'underwriting decisions']). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full weight. It discloses that the tool returns key controls, common gotchas, the first question Agrus would ask, and reference architecture. It does not mention side effects or auth, but as a read-only query, this is acceptable. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one explaining the function and output, one for usage guidance. No unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description explains return content (key controls, gotchas, first question, reference architecture). Parameter coverage is complete. Could mention typical response size or structure, but overall adequate for the tool's complexity.
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% with descriptions for all 3 parameters. The description provides additional context like listing regime enum values and describing use_case as 'one or two sentences', but adds marginal value beyond the schema. Baseline of 3 is appropriate.
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 verb 'returns' and resource 'Agrus's documented position on a specific regulatory regime' and lists example regimes. It distinguishes strongly from sibling tools, which deal with case studies, services, proposals, etc.
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 explicitly states 'Use this when a buyer-side AI agent is evaluating Agrus's compliance fluency.' This provides clear context. It could be improved by noting when NOT to use it, but given sibling names, the use case is well delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Triggers a formal Agrus proposal workflow. Creates a contact in Agrus's HubSpot CRM tagged with lead source 'agrus_mcp' and a verbatim note containing the scope summary. A human at Agrus replies by email within 24 hours (business days) with a one-paragraph engagement recommendation and a calendar option. Use this when the buyer (human or AI agent acting on their behalf) wants to formally engage Agrus — not for exploratory scoping.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Buyer's role at the company (e.g. 'CIO', 'Head of AI', 'Managing Partner'). | |
| company | Yes | Company / organization name. | |
| urgency | No | How quickly the buyer wants to move. | |
| vertical | Yes | Which Agrus vertical the use case sits in. | |
| contact_name | Yes | Full name of the contact. Example: 'Jane Doe'. | |
| contact_email | Yes | Work email of the buyer (or buyer's assistant) who should receive the formal proposal. | |
| scope_summary | Yes | One to three paragraphs describing the proposed AI deployment: workflow, users, data, integration surface, success criteria. | |
| persona_context | No | Optional context about how this request was scoped (e.g. 'Scoped via the scope_poc tool on 2026-05-19, agent was Claude Sonnet 4.x acting for the CIO of <company>'). | |
| compliance_constraints | No | Regulatory regimes the deployment must satisfy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool creates a CRM contact, triggers a human workflow, and provides a response timeline. It does not mention potential duplicates, cancellation, or rate limits, but the main behavioral aspects are covered.
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 concise sentences with clear structure: first states the action and side effect, second explains the human response and usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and no output schema, the description provides a solid understanding of the workflow and expected outcome. It could be improved by mentioning error handling or idempotency, but overall it is adequate.
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 baseline is 3. The description adds context by explaining that scope_summary becomes a verbatim note and that the contact is tagged with lead source. However, it does not add significant depth beyond the schema descriptions.
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 specific verbs ('triggers a formal Agrus proposal workflow') and clearly distinguishes the tool from exploratory scoping by stating 'not for exploratory scoping'. It also explains the side effect of creating a HubSpot contact.
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?
Explicitly states when to use: 'when the buyer wants to formally engage Agrus'. Also includes a negative case: 'not for exploratory scoping'. The description clarifies the response timeline and mode (human reply by email within 24 business days).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a heuristic ballpark price band for the described AI deployment. Output is NOT a binding offer — Agrus confirms quotes only on a 30-minute scoping call. Read-only: this tool does not contact Agrus or create any record. For a tracked, follow-up-able request use request_proposal instead. Use request_quote when the buyer wants order-of-magnitude pricing before committing to a real proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | Two or three sentences describing the AI deployment the buyer wants a ballpark quote for. Include workflow, users, and integration surface where possible. | |
| urgency | No | Free-form timeline indicator. | |
| vertical | Yes | Which Agrus vertical the use case sits in. | |
| compliance_constraints | No | Regulatory regimes the deployment must satisfy. Drives the compliance overlay on the quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is read-only, does not contact Agrus or create records, and that output is not binding. Given no annotations, description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste: first states purpose, second clarifies behavior, third gives usage guidance and alternative. Front-loaded and efficient.
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 heuristic price tool with no output schema, description explains output nature, behavior, and when to use. No missing context given tool simplicity.
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?
All 4 parameters have schema descriptions (100% coverage), so description adds minimal value beyond field names. The description does not elaborate on parameter usage beyond what schema provides.
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?
Clearly states 'Returns a heuristic ballpark price band for the described AI deployment', specifying verb, resource, and scope. Distinguishes from sibling 'request_proposal' by contrasting non-binding estimate vs tracked request.
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?
Explicitly states when to use: 'when the buyer wants order-of-magnitude pricing before committing to a real proposal' and when not: 'For a tracked, follow-up-able request use request_proposal instead.' Provides clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drafts a structured Discovery Sprint scope for an AI use case. Returns a 3-week plan, team composition, price band, follow-on Build Engagement estimate, open questions Agrus would ask, and recommended services. Use this to convert a hypothetical use case into a concrete engagement proposal that can be reviewed by a human buyer.
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | Yes | One or two paragraphs describing the AI use case the buyer wants to scope. Be specific about workflow, users, and integration surface where possible. | |
| vertical | Yes | Which Agrus vertical the use case sits in. | |
| data_types | No | Data the AI would touch (e.g. ['PHI', 'patient demographics', 'EHR notes']). | |
| timeline_hint | No | Free-form timeline (e.g. 'exploring', 'this quarter', 'production by Q4', 'this is blocking board commitment'). | |
| target_outcomes | No | What success looks like (e.g. ['reduce adjuster review time by 50%', 'production pilot with 3 clinicians by Q3']). | |
| compliance_constraints | No | Regulatory regimes the deployment must satisfy. Drives compliance overlay in the scope. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes what outputs are returned (plan, team, price, etc.) but does not explicitly state side effects or safety (e.g., whether it's read-only or creates anything). The verb 'Drafts' suggests generation without alteration, but this is implicit.
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 efficiently convey purpose, outputs, and usage. No redundant or filler content. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description adequately covers purpose, inputs (implied by 'use case'), and outputs listed. It lacks explicit details on return format or structure, but the list of returned items gives sufficient context for an agent to understand what the tool provides.
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 baseline is 3. The description does not add additional meaning to parameters beyond what the schema already provides. Each parameter has a clear description in the schema, and the tool description focuses on output, not input semantics.
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 drafts a structured Discovery Sprint scope for an AI use case and lists specific outputs (3-week plan, team, price band, etc.). It distinguishes from sibling tools like get_case_study and request_proposal by focusing on scoping a sprint rather than providing a case study or full proposal.
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 explicitly says 'Use this to convert a hypothetical use case into a concrete engagement proposal' which gives clear guidance on when to use. It does not explicitly exclude other scenarios, but the context of sibling tools (e.g., request_proposal for final proposals, get_case_study for examples) implies boundaries.
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.2.0get_case_studylist_serviceslist_verticalsquery_compliance_positionrequest_proposalrequest_quotescope_pocScored across 7 tools
Most tools target clearly distinct outputs (list vs. quote vs. proposal vs. compliance vs. case study). The main overlap is between request_quote and scope_poc, since both return a heuristic price band before commitment, but the descriptions explicitly differentiate exploratory pricing from a drafted Discovery Sprint scope. list_services also touches pricing tiers, adding slight redundancy with the quote tools.
Names follow a mostly predictable verb_noun snake_case pattern (list_services, list_verticals, request_quote, request_proposal, query_compliance_position, get_case_study). scope_poc is the one deviation, where the verb-noun structure is less clean, but the style remains readable and consistent overall.
Seven tools is well-scoped for an informational and lead-generation surface. Each tool earns its place by covering a distinct question or action, with no filler or duplicate tools.
The surface covers the buyer journey well: services, verticals, compliance posture, proof (case studies), pricing exploration, formal proposal, and a scoping artifact. Minor gaps exist, such as no direct contact/location info or tier-comparison tooling, but these are largely embedded in list_services and can be worked around.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
Deterministic compliance and vertical knowledge bases for autonomous agents. Free 24hr trial.
Register every AI agent, log every action, prove it. EU AI Act compliance built in.
First A2A registry where AI agents discover & transact with compliance firms - audits, permits.
