Carragent's AI agents for small businesses, its plans and prices. Read-only, no key.
Scored across 4 tools
Each tool has a fairly distinct role: list_agents browses all agents, get_agent retrieves one by id, list_plans handles pricing, and search_carragent finds by keyword across agents and plans. The main overlap is that search_carragent can return agents, which could be confused with list_agents, but the descriptions clarify the intended use cases.
All names follow a snake_case verb_noun pattern (get_agent, list_agents, list_plans, search_carragent). The only minor deviation is that search_carragent uses the server name as the object instead of a specific resource, while the others target agents or plans explicitly.
Four tools is a compact, well-scoped set for a read-only catalog of agents and plans. It is on the lean side but each tool earns its place, with no obvious redundancy.
The surface covers the core read-only needs: browsing all agents, getting one agent's details, listing plans, and keyword search across both. A minor gap is the lack of a get_plan tool to retrieve a specific plan by id, though list_plans already exposes full plan details.
Get one agent by id (for example collections, scheduling, leads, reviews, report). Use after list_agents or search_carragent to give the details of one agent.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The agent id, from list_agents. | |
| lang | No | Language of the text: en, es or fr. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the full safety profile. The description adds no behavioral context beyond that (no note on what is returned, error behavior for a bad id, or localization effect of lang), so it contributes little past the structured fields.
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 short sentences, front-loaded with the action and followed by routing guidance; little is wasted. The clause 'to give the details of one agent' mildly restates the opening verb.
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 read-only lookup with full schema coverage, existing annotations, and no output schema to explain, the description supplies what an agent needs to select and call it. Only marginal gaps (bad-id behavior) remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema; baseline is 3. The description only adds that the id comes from list_agents, a small reinforcement rather than new syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one agent by id') and gives example ids, so the agent knows exactly what is retrieved. It is distinguishable from list_agents and search_carragent by scope, though the parenthetical example list is slightly ambiguous about whether those are ids or agent categories.
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 sequences the tool: 'Use after list_agents or search_carragent,' naming the alternatives that precede it. No when-not guidance is given, but the workflow position is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Carragent AI agent: what it does, when it runs, what waits for the owner's approval, what it never does and which tools (Stripe, Google Calendar, HubSpot…) it connects to. Use to answer 'what can Carragent do?'.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the text: en, es or fr. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuinely new context by describing what each returned record contains (behavior, schedule, approval requirements, exclusions, integrations), which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the scope ('every agent') and the payload contents front-loaded before the usage trigger. The enumeration is long but every item conveys distinct returnable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the burden of explaining what comes back, and it does so adequately by listing the fields of interest. It does not mention pagination or result volume, a minor gap for a no-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'lang' parameter with an explicit enum and default, so the schema fully documents it. The description adds nothing about language selection; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every Carragent AI agent') and enumerates the substance of each entry (behavior, schedule, approval gates, connected tools), which is far more than a restatement of the name. It does not explicitly distinguish itself from siblings get_agent or search_carragent, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use to answer "what can Carragent do?"' gives a concrete trigger for invocation rather than leaving usage implicit. It offers no exclusions or named alternatives (e.g., use get_agent for a single agent), so it is clear context without routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the plans with monthly and yearly prices in USD cents (plus applicable taxes), their limits, the free-trial length and the refund terms. Use to answer 'how much does Carragent cost?'.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the text: en, es or fr. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description goes beyond that by disclosing the shape of the returned data (USD cents, plus applicable taxes, limits, trial length, refund terms), which is genuinely useful context. It does not describe ordering, pagination, or how many plans exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, and the content enumeration is front-loaded before the usage hint. Nothing to trim.
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 exists, and the description compensates by enumerating the returned fields and their units (USD cents, taxes, limits, trial, refunds). Combined with full annotation coverage, an agent has everything needed to call it and interpret results.
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 single parameter (lang) has 100% schema description coverage with an enum and a default, so the schema fully documents it. The description adds nothing about language handling or localization of prices, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (plans) and enumerates the payload — monthly/yearly prices in USD cents, limits, free-trial length, refund terms. This is immediately distinguishable from the agent-oriented siblings (get_agent, list_agents, search_carragent).
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 a concrete trigger: 'Use to answer how much does Carragent cost?'. That is clear positive guidance, but it names no alternatives or exclusions — though the sibling set is obviously unrelated, so the gap is small.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over Carragent's agents and plans, best match first. Use to find the agent for a task, such as 'chase late invoices' or 'confirm appointments'.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the text: en, es or fr. | en |
| query | Yes | What the user needs, in their words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive), so the description's real contribution is behavioral: it discloses ranked output ('best match first') and that the index spans both agents and plans. It does not cover result limits or pagination, but adds meaningful context beyond the 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?
Two sentences, zero filler, with the ranked-retrieval behavior front-loaded before the usage example. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with full schema coverage, rich annotations, and no output schema, the description covers purpose, intent, and ranking adequately. Minor gaps remain around result volume/pagination, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (query, lang) are already documented, giving a baseline of 3. The description reinforces query semantics as keyword-based and free-form ('in their words') but adds no syntax, length, or language-handling detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (keyword search), the resource (agents and plans), and the ordering semantics (best match first), which implicitly contrasts with the enumeration siblings list_agents/list_plans. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.
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 second sentence gives a clear when-to-use context ('find the agent for a task') plus two concrete example queries that anchor intent. There is no guidance on when to prefer list_agents/get_agent instead, so exclusions are absent.
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.
get_agentlist_agentslist_planssearch_carragentReady-made AI agents for small businesses: what each one does, prices and how to start.
AI support agent platform for small businesses. Query pricing, features, and examples.
Evidence-backed opportunity intelligence for small businesses, built for authorised AI agents.
Web scraping for agents. Point it at a URL and it returns the page as clean markdown, JavaScript-rendered pages included. Point it at a site and it maps the URLs or crawls the section you need in the background, a few pages at a time so results fit in the conversation. Search the web and read full pages, extract fields with a JSON schema you define (validated, never invented), read a store's catalogue or a blog's posts from the platform's own feed, and check whether a page has changed. Failed requests cost nothing. The free plan includes 1,500 credits a month.
Add one secure layer between your agents and this server.
