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 clearly different information. match_intent and recommend_path are the only pair with soft overlap since both return next-step URLs, but the descriptions differentiate them (classify unknown intent vs. resolve a known goal), so an agent can still choose correctly.
All five tools follow the same verb_noun snake_case pattern (get_pricing, list_services, match_intent, recommend_path, understand_site). No casing or verb-style deviations.
Five tools is well-scoped for a lightweight site-guide/routing server. Each tool covers a distinct facet (overview, pricing, services, intent classification, path resolution) with no filler.
The surface covers the main visitor journeys: orientation, pricing, service catalog, and URL routing for hire/job/client/Agent API intents. Minor gaps exist, such as no dedicated tool for existing-client or Agent API specifics beyond a routing URL, but agents can work around this.
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, or Agent API) and return the next URL. Job seekers are never hire conversions.
| 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add domain behavior. It does: the business rule that job-seeker traffic is never treated as a hire conversion, which materially affects how the classification result should be interpreted and cannot be inferred from 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. The purpose and intent categories come first, the return value second, and the exception rule last where it belongs.
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 detail the response shape, and it is complete on inputs and intent taxonomy. It stops just short of distinguishing this classifier from the similarly oriented recommend_path sibling, which is the one thing an agent might still second-guess.
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% with only two parameters (message, pageUrl) and both are documented in the schema with their caps. The description adds no format syntax, examples, or guidance on how pageUrl affects classification, so baseline 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?
States a specific verb (classify) and resource (visitor/AI intent on taskbullet.com) and enumerates the actual intent classes it resolves: hire a VA, apply for a job, existing client, Agent API. It also names the output (the next URL), so an agent knows what comes back without opening the output 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?
Usage is implied: call this to route a visitor based on a free-text message. However, it never says when to prefer it over siblings like recommend_path or understand_site, and no prerequisites or exclusions for the tool itself are given — the only routing rule ('Job seekers are never hire conversions') governs classification output, not tool selection.
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_siteCross-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.
Public services, guide/FAQ search and estimates. Inquiry drafts require scoped authentication.
Add one secure layer between your agents and this server.
