Public, no-auth MCP for taskbullet.com: services, pricing, intent routing and the right next URL.
Scored across 5 tools
get_pricing, list_services, and understand_site each target a clearly distinct kind of content. match_intent and recommend_path both return a URL and are the closest pair, but the descriptions draw the boundary (use match_intent when the goal is unclear, recommend_path for a known goal). The only snag is that match_intent's description is cluttered with phone-wallet/trial-grant details that don't belong to a classification tool.
All five tools follow a clean verb_noun snake_case pattern (get_pricing, list_services, match_intent, recommend_path, understand_site). No mixed conventions or casing inconsistencies.
Five tools is well-scoped for a site-guide/orientation server: one for orientation, one for services, one for pricing, and two for routing. Nothing feels redundant or missing from a count perspective.
The surface covers the main visitor lifecycle: understand the site, browse services, check pricing, classify intent, and route to a URL. Minor gaps exist — there's no dedicated tool for the job-seeker application flow or for surfacing the phone/call path referenced in the match_intent description, forcing agents to rely on a returned URL.
Return current PH and US bucket pricing and the free-trial URL.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Which team rates to return. Defaults to both. |
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usBased | No | |
| currency | Yes | |
| freeTrial | Yes | |
| pricingPage | Yes | |
| allPlansInclude | Yes | |
| philippinesBased | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that the data is 'current' (implying live, not cached) and that it includes a free-trial URL, which is modest but real added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. The primary payload (BCN pricing) leads, and the secondary artifact (free-trial URL) trails.
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?
An output schema exists, so return-value explanation is unnecessary, and with zero required parameters and full schema coverage, an agent has everything needed to invoke the tool correctly. The description covers scope (PH and US) and content (pricing plus free-trial URL) adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'team' parameter and its ph/us/both enum are already fully documented in the schema. The description names PH and US, loosely echoing the enum, but adds no format or default semantics beyond what the 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?
The description states a specific verb and resource ('Return current PH and US bucket pricing') plus an additional artifact ('the free-trial URL'). The purpose is clear, but it does not differentiate itself from any sibling tool (list_services, match_intent, recommend_path, understand_site), which the 5-level requires.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent infers this is the tool to call when pricing/free-trial information is needed. There is no explicit when-to-use, no when-not-to-use, and no mention of alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List TaskBullet VA service categories and common tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional filter, e.g. shopify or real estate. Capped at 80 characters. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| services | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing behavioral on top — no note about filtering behavior, result grouping, or how 'common tasks' relate to categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. It is efficient, though the brevity borders on under-specification for a tool that returns a grouped catalog.
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?
An output schema exists, so return values need not be explained, and the one optional parameter is documented. The description is minimum viable: it never clarifies what a 'service category' versus a 'common task' means in the returned structure, which would help an agent use the list correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional 'query' parameter is documented with examples and the 80-character cap. The description adds no filtering semantics beyond the schema, so the baseline 3 is correct.
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 a specific resource ('TaskBullet VA service categories and common tasks'), so the agent knows exactly what comes back. It does not need to name siblings because none of get_pricing/match_intent/recommend_path/understand_site overlap, but it also doesn't explicitly differentiate itself.
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?
There is no when-to-use guidance, no statement of when this is preferable to get_pricing or understand_site, and no mention of prerequisites or exclusions. Usage is only weakly implied by the word 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify what a visitor or their AI wants from taskbullet.com (hire a VA, apply for a job, existing client, Agent API, or a phone call) and return the next URL. Job seekers are never hire conversions. A phone-wall agent uses place_call and the calls wallet (POST /api/v1/accounts, pay-as-you-go). New accounts receive a $20 trial grant (10 hours). Do not spend those hours on the call.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What the visitor said or asked. Capped at 2000 characters. | |
| pageUrl | No | Optional page they are on. Capped at 500 characters. |
| Name | Required | Description |
|---|---|---|
| ask | Yes | |
| reply | Yes | |
| audience | Yes | |
| nextUrls | Yes | |
| isHireConversion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description usefully adds that the output is a redirect/next URL plus one domain rule about job seekers, but then pivots to phone-wallet and $20 trial-grant operational detail that has nothing to do with classification 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?
The opening sentence is well front-loaded, but the bulk of the text is off-topic operator instruction about place_call, the calls wallet, POST /api/v1/accounts, and the $20 trial grant. Those sentences do not help an agent decide to call match_intent and actively dilute the one relevant rule that precedes them.
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?
An output schema exists, so return values needn't be explained, and the required message param is documented in the schema. What remains missing is sibling differentiation and any sense of what the classifier considers ambiguous or how confident a match must be — instead the space is spent on billing trivia.
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% and both parameters (message, pageUrl) carry their own descriptions and length caps, so the schema does the work. The description adds no meaning about what to put in message or how pageUrl influences classification, which is the baseline 3 case.
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 first sentence states a concrete verb (classify), the resource (visitor/AI intent for taskbullet.com), enumerates the intent buckets it distinguishes, and says it returns the next URL. That is specific enough to act on, though it never contrasts itself with siblings like recommend_path or understand_site, which sound adjacent.
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 gives classification rules ('Job seekers are never hire conversions') rather than invocation guidance. There is no statement of when to call this instead of recommend_path, understand_site, get_pricing, or list_services, so routing between siblings is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical URL for a known goal. Use match_intent when the goal is unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| goal | Yes | |
| note | Yes | |
| isHireConversion | Yes |
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 entire safety profile of this lookup. The description adds no behavior beyond that - no note on auth, caching, or what happens on an unrecognized goal - so there is essentially nothing beyond 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, zero filler, with the core purpose front-loaded and the routing hint second. 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?
With an output schema present, return values need no explanation, and the rich annotations cover the safety profile for a simple one-enum lookup. The only residual gap is that nothing explains which URL each goal resolves to, though the closed enum makes that largely inferable.
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 0%, but the single parameter is a closed enum whose six values (hire, pricing, how_it_works, agent_api, apply_to_work, existing_client) are largely self-explanatory. The description only says 'known goal' and adds no meaning about how each value maps to a destination, so it neither compensates for nor harms the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and return artifact ('Return the canonical URL') plus the scoping constraint ('for a known goal'), and explicitly names the sibling it must not be confused with (match_intent). An agent can distinguish this from match_intent, get_pricing, and understand_site without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit routing rule with both halves: use this tool when the goal is already known, and use match_intent when the goal is unclear. That is a when-to-use plus a named alternative, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What TaskBullet is, who the site is for, and what the site wants from a visitor. Call this first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| icp | Yes | |
| company | Yes | |
| not_for | Yes | |
| tagline | Yes | |
| for_agents | Yes | |
| description | Yes | |
| mcp_endpoint | Yes | |
| conversion_paths | Yes | |
| what_the_site_wants | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safe, repeatable read profile is fully covered by structured fields. The description adds only that this is a first-step orientation call and says nothing new about return format or behavior, which is acceptable given the annotation coverage but not additive.
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 with the content summary front-loaded and the actionable instruction ('Call this first') placed at the end. Every clause earns its place; nothing is padded.
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 an output schema present, the description need not explain return values, and with zero parameters there is no input complexity to cover. It conveys the purpose and the invocation order, leaving only sibling-level routing detail unstated.
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 tool takes no parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-related claims are made or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool returns: the site's identity, audience, and desired visitor action, which is a clear content-focused purpose rather than a tautology of the name. It implicitly differentiates from siblings like get_pricing or recommend_path by being the orientation tool, but it never names them to make the contrast explicit.
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?
'Call this first' gives an explicit ordering rule that tells the agent when to invoke it relative to other tools. There is no explicit when-not or named alternative, but the sequencing instruction is unambiguous for a zero-argument orientation tool.
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_pricing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "allPlansInclude": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "freeTrial": {
+ "additionalProperties": false,
+ "properties": {
+ "creditCardRequired": {
+ "type": "boolean"
+ },
+ "hours": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hours",
+ "creditCardRequired",
+ "url"
+ ],
+ "type": "object"
+ },
+ "model": {
+ "type": "string"
+ },
+ "philippinesBased": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hours": {
+ "type": "number"
+ },
+ "monthlyRate": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "perHour": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "hours",
+ "monthlyRate",
+ "perHour"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pricingPage": {
+ "type": "string"
+ },
+ "usBased": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hours": {
+ "type": "number"
+ },
+ "monthlyRate": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "perHour": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "hours",
+ "monthlyRate",
+ "perHour"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "model",
+ "currency",
+ "allPlansInclude",
+ "freeTrial",
+ "pricingPage"
+ ],
+ "type": "object"
+}list_services3 fields changedInput schema / properties / query / descriptionPrevious value: -"Optional filter, e.g. shopify or real estate."New value: +"Optional filter, e.g. shopify or real estate. Capped at 80 characters."Input schema / properties / query / maxLengthAdded value: +80Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "query": {
+ "maxLength": 80,
+ "type": "string"
+ },
+ "services": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "commonTasks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "url",
+ "description",
+ "commonTasks"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "services"
+ ],
+ "type": "object"
+}match_intent5 fields changedInput schema / properties / message / descriptionPrevious value: -"What the visitor said or asked."New value: +"What the visitor said or asked. Capped at 2000 characters."Input schema / properties / message / maxLengthAdded value: +2000Input schema / properties / pageUrl / descriptionPrevious value: -"Optional page they are on."New value: +"Optional page they are on. Capped at 500 characters."Input schema / properties / pageUrl / maxLengthAdded value: +500Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "ask": {
+ "type": "string"
+ },
+ "audience": {
+ "enum": [
+ "hire_va",
+ "work_va",
+ "needs_intent",
+ "existing_client",
+ "ai_agent"
+ ],
+ "type": "string"
+ },
+ "isHireConversion": {
+ "type": "boolean"
+ },
+ "nextUrls": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "reply": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "audience",
+ "isHireConversion",
+ "ask",
+ "reply",
+ "nextUrls"
+ ],
+ "type": "object"
+}recommend_path1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "goal": {
+ "enum": [
+ "hire",
+ "pricing",
+ "how_it_works",
+ "agent_api",
+ "apply_to_work",
+ "existing_client"
+ ],
+ "type": "string"
+ },
+ "isHireConversion": {
+ "type": "boolean"
+ },
+ "note": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "goal",
+ "isHireConversion",
+ "url",
+ "note"
+ ],
+ "type": "object"
+}understand_site1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "company": {
+ "type": "string"
+ },
+ "conversion_paths": {
+ "additionalProperties": false,
+ "properties": {
+ "agent_api": {
+ "type": "string"
+ },
+ "apply_to_work": {
+ "type": "string"
+ },
+ "existing_client": {
+ "type": "string"
+ },
+ "for_ai_agents": {
+ "type": "string"
+ },
+ "hire_trial": {
+ "type": "string"
+ },
+ "how_it_works": {
+ "type": "string"
+ },
+ "pricing": {
+ "type": "string"
+ },
+ "site_mcp": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hire_trial",
+ "pricing",
+ "how_it_works",
+ "agent_api",
+ "for_ai_agents",
+ "site_mcp",
+ "existing_client",
+ "apply_to_work"
+ ],
+ "type": "object"
+ },
+ "description": {
+ "type": "string"
+ },
+ "for_agents": {
+ "type": "string"
+ },
+ "icp": {
+ "type": "string"
+ },
+ "mcp_endpoint": {
+ "type": "string"
+ },
+ "not_for": {
+ "type": "string"
+ },
+ "tagline": {
+ "type": "string"
+ },
+ "what_the_site_wants": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "company",
+ "what_the_site_wants",
+ "tagline",
+ "description",
+ "icp",
+ "not_for",
+ "for_agents",
+ "mcp_endpoint",
+ "conversion_paths"
+ ],
+ "type": "object"
+}get_pricinglist_servicesmatch_intentrecommend_pathunderstand_siteHeadless task management for bots, apps and AI agents. Remote MCP server, OAuth or access token.
Cross-product MCP server for CRM, LeadKit, ProjectKit, Bookio. 10 action types, MIT open spec.
Public MCP for gethal.ai — autonomous AI sales agent. Pricing, features, book a demo.
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Add one secure layer between your agents and this server.
