Ask Portaur about its services and leave a message or callback request for the team.
Scored across 8 tools
The read tools (about_portaur, list_services, pricing_approach) each target a distinct fact category, and ask_portaur explicitly positions itself as the fallback for questions the others don't answer, which defuses most overlap. contact_options is meta-guidance rather than a data fetch, which is clearly signposted, but an agent may still occasionally pick ask_portaur where a specific read tool would do.
All names are lowercase snake_case with a predictable resource-or-action noun, and the split between noun-phrase read tools (about_portaur, list_services, pricing_approach, contact_options) and verb_phrase action tools (send_message, request_callback, request_status) is a coherent, readable convention. It is not a strict single verb_noun pattern throughout, so it falls just short of perfect.
Eight tools is well-matched to a small company-info plus contact server: four read tools, two submission tools, a status lookup and a guidance tool. Nothing feels bloated or thin, and each tool earns its place.
The surface covers information retrieval (about, services, pricing, contact), both contact paths (send_message, request_callback), and follow-up via request_status with handles, so the lifecycle is essentially closed. Minor gaps: no way to cancel or withdraw a submitted request, and no explicit tool for confirmation-email resend.
Returns facts about Portaur LLC, the company behind portaur.com: who it is, its mission, its founder, how to reach it, and the public pages that say more. Read only. The facts are the ones Portaur publishes on its own site. It never returns prices, client names or anything private.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, and closed-world, so the bar is lower, yet the description still adds real boundaries: facts are sourced from Portaur's own site and it never returns prices, client names, or private data. That negative scoping is valuable behavioral context beyond the annotations. It stops short of describing response format, though no output schema exists to cover that gap.
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?
Front-loads the identity and payload in the first sentence, then adds provenance and exclusions in short, non-overlapping clauses. No filler and nothing that could be cut without losing routing 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 zero parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the fact categories plus an explicit exclusion list. Nothing an agent needs to call this zero-argument tool correctly 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?
The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly does not waste space restating an empty 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 plus resource ('Returns facts about Portaur LLC') and enumerates the content the caller can expect: identity, mission, founder, contact, and public page links. This clearly differentiates it from siblings like list_services or contact_options, which cover narrower slices of company information.
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 implies usage by scoping the tool to published company facts and stating 'Read only', but it never says when to pick this over ask_portaur (a free-form question tool) or contact_options. The agent must infer the boundary from the returned-content list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Asks Portaur's own assistant one question about Portaur and returns its answer, written from the same facts as the website. Read only: the question is answered once and not kept. Use it for a question the other read tools do not answer. It answers only about Portaur, never gives prices, and has a daily limit; once the limit is reached it says so.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | One question about Portaur. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description still adds that the question is answered once and not kept, that answers come from the same facts as the website, and that a daily limit exists with an explicit signal when hit. That is meaningful context beyond the annotations. It stops short of describing answer format or latency, which is a minor gap only.
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?
Four short sentences, front-loaded with what the tool does before the usage routing and the limitations. Every clause carries information — verb, scope, read-only behavior, sibling routing, exclusions, rate limit — with no filler.
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?
There is no output schema, and the description compensates by saying it returns an answer grounded in the website's facts, plus how the daily-limit failure surfaces. For a one-parameter read tool, nothing an agent needs in order to call it correctly 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 coverage is 100% and the single parameter already documents its purpose and length bounds, so the description need not repeat it. The description reinforces the cardinality constraint (one question) but adds no detail the schema lacks.
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 ("asks Portaur's own assistant one question about Portaur and returns its answer") and scopes it to Portaur-only content. It also distinguishes itself from the sibling read tools by saying it is for questions the others do not answer.
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 routes the agent: use this only for a question the other read tools do not answer, which directly contrasts with siblings like about_portaur, list_services and pricing_approach. It also gives exclusion conditions — no prices, one question per call — so the agent knows 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.
Explains the ways to reach a person at Portaur and what each needs: a written message, a request for a phone call back, or an email. It also explains the confirmation email that follows a request. Read only. Call it before send_message or request_callback to learn what to ask the person for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the "Read only" sentence is largely redundant. What the description does add is the content domain (the three channels and the confirmation email it documents), but it is silent on the shape of the return, since there is no output schema. Useful but thin 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, front-loaded with the purpose and ending with the sequencing rule, which is the most actionable part. The middle clause listing the three channels runs a little long but each element maps to real content. Minor redundancy with the "Read only" annotation.
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 no-parameter, read-only informational tool with no output schema, the description covers what it explains and when to consult it. It leaves the exact output format unspecified, but for a documentation-style tool that is a small gap.
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 zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies no input is required by framing the tool as purely explanatory.
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 purpose: enumerating the ways to reach a person at Portaur (message, callback request, email) plus the follow-up confirmation email. It names the downstream siblings send_message and request_callback, so an agent can tell it apart from the action tools. It is only loosely differentiated from the informational siblings about_portaur and ask_portaur, which keeps it from 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?
Gives an explicit precondition: call it before send_message or request_callback to learn what to ask the person for. That is real routing guidance tied to named alternatives. It stops short of saying when not to bother calling it (e.g., if the needed details are already known).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the services Portaur offers, each with its name, a plain language summary and a fuller description, exactly as portaur.com states them. Read only. It never returns prices; pricing_approach explains how pricing works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Read only' repeats structured data rather than adding it. However, the description does add substantive behavioral context: the result is verbatim from portaur.com and never includes prices, which sets expectations for output content. It says nothing about result size, ordering, or whether the list can change over time.
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 short sentences, front-loaded with what it returns and followed by the read-only and no-prices constraints. No filler or restated title language beyond the useful scope statement.
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 read tool with no output schema, the description must carry the return shape, and it does (name, summary, description, verbatim from the site). Minor gap: no indication of how many services come back or whether the response is paginated, so an agent can't anticipate payload size.
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 zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies a full unfiltered listing rather than a search.
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 (lists) and resource (Portaur services) and specifies exactly what each item contains: name, plain-language summary, fuller description. That detail distinguishes it from siblings like about_portaur or pricing_approach without opening a 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?
Explicitly excludes a plausible wrong use case — 'It never returns prices' — and names the correct alternative, pricing_approach. It lacks an explicit 'use this when the user asks about what Portaur offers' clause, but the routing guidance against the nearest sibling is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains how Portaur prices its work. Read only. It returns no figures: Portaur never quotes a price through an assistant, and every project is scoped with a person.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds meaningful context beyond that: the response contains no prices and pricing is never transacted through the assistant. It doesn't say what the explanation actually covers (factors, process, ranges), leaving the returned content partly opaque.
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 short sentences with no filler. The core purpose is front-loaded and the two constraints (no figures, human scoping) follow in priority order.
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, annotation-covered tool with no output schema, the description gives enough to call it safely and set expectations about the response. A brief note on what the explanation does contain would close the remaining gap.
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 zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument call by describing the tool as a pure explanation.
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 ("Explains how Portaur prices its work") and immediately narrows expectations by noting it returns no figures. It implicitly separates itself from ask_portaur and contact_options, but never names a sibling explicitly, so the differentiation is by negation rather than direct routing.
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 returns no figures" plus "every project is scoped with a person" gives a clear when-not condition: don't call this expecting a quote. It stops short of naming the alternative tool an agent should use to actually request a quote or a callback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Asks a person at Portaur to telephone the person you are helping. Needs their name, email address, phone number and the reason for the call; a preferred time window is optional. Use it only when the person asked to be called. It stores the request in Portaur's inbox and sends one email to the address given, asking the person to confirm; Portaur's phone is alerted only after they do. A person makes the call by hand: nothing ever dials or texts the number. Returns a handle for request_status. It never sends anything to anyone else and never quotes a price.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the person who wants a call. | |
| Yes | Their email address. Portaur sends one confirmation email here. | ||
| phone | Yes | The number to call: 7 to 15 digits, with spaces and + ( ) . allowed. | |
| reason | Yes | What the call is about. | |
| window | No | When they would like the call, with their time zone. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the storage location (Portaur's inbox), the exact side effect (one confirmation email to the given address), the sequencing (Portaur's phone is alerted only after confirmation), and the human-in-the-loop nature ('nothing ever dials or texts the number'). The negative guarantees ('never sends anything to anyone else', 'never quotes a price') close off likely agent failure modes.
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?
Purpose is front-loaded, then requirements, then the usage gate, then side effects. Every sentence carries distinct information — no restatement of the title or the schema's format constraints.
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 5-parameter write tool with no output schema, the description covers what is created, what is sent, to whom, in what order, and what is returned ('a handle for request_status'). Nothing an agent needs in order to call it safely 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 coverage is 100%, so the schema already carries the field-level detail; the description still adds functional meaning by tying email to 'one confirmation email' and phone to 'the number to call'. It also flags window as optional, matching the required list, without duplicating format rules the schema already states.
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 names a specific verb and resource ('Asks a person at Portaur to telephone the person you are helping') rather than restating the tool name. It is clearly separable from siblings send_message (message, not a call) and request_status (which it explicitly hands off to via the returned handle).
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 a firm gating condition: 'Use it only when the person asked to be called,' which tells the agent when not to invoke it. It does not name the sibling to use instead when the person wants an email or message, so the alternative path is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Says how a request made with send_message or request_callback is doing, given the handle that tool returned: waiting for the person to confirm their email, confirmed and the owner has been told, or not found. Read only. It never returns the message or the address.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The handle send_message or request_callback returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the description reinforces the read-only nature. It adds useful behavioral detail by listing the possible status results and explicitly stating that the message and address are never returned, though it does not discuss auth, rate limits, or handle expiry.
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 front-loaded with the core purpose and then adds the possible outcomes, read-only note, and privacy constraint in two short sentences. Every sentence contributes useful information with no waste.
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 one-parameter, read-only status tool with no output schema, the description provides enough detail about return states and explicitly rules out returning sensitive content. An agent can call this correctly without additional context.
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 handle parameter is already fully documented in the schema. The description restates that the handle comes from send_message or request_callback but adds no syntax, format, or validation 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?
The description states a specific purpose: checking the status of a request created by send_message or request_callback using the returned handle. It names the sibling tools and enumerates the possible outcomes, so an agent can distinguish it from the creation tools without opening the 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?
The description clearly ties use to handles returned by send_message or request_callback, which implies the post-submission polling context. It does not explicitly state when not to use it or name an alternative status-checking tool, but the intended usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leaves a written message for a person at Portaur on behalf of the person you are helping. Needs their name, their email address and the message; a subject is optional. Use it only when the person asked you to contact Portaur. It stores the message in Portaur's inbox and sends one email to the address given, asking the person to confirm; nothing reaches a person's phone until they do. Returns a handle for request_status. It never sends anything to anyone else, never calls or texts anyone, and never quotes a price.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The message, in their words. | |
| name | Yes | The name of the person you are writing for. | |
| Yes | Their email address. Portaur sends one confirmation email here. | ||
| subject | No | A short subject line. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the delivery pipeline: message is stored in Portaur's inbox, exactly one email goes to the supplied address, and nothing reaches the person's phone until they confirm. It also states the return value (a handle for request_status) and hard boundaries, which an agent needs before triggering an open-world, non-idempotent send.
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?
Purpose first, then required inputs, then the usage gate, then side effects and return value. No sentence is redundant — each adds a distinct constraint or behavioral fact.
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 still tells the agent what comes back (a request_status handle), and it covers the confirmation side effect, the recipient scope and the forbidden actions. Nothing needed to invoke this correctly 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: name/email/body are required and subject optional, and the email is where 'one confirmation email' goes. It also clarifies the name and email belong to the person being helped, not the agent.
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?
A specific verb+resource ('leaves a written message for a person at Portaur') with the acting perspective spelled out ('on behalf of the person you are helping'). It also fences itself off from siblings: 'never calls or texts anyone' distinguishes it from request_callback, and 'never quotes a price' from pricing_approach.
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 it only when the person asked you to contact Portaur' is an explicit inclusion condition, and the closing sentence enumerates what it must not be used for (no calls, texts, other recipients, price quotes). No alternative tool is named by name, which keeps it just short of a 5.
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.
about_portaurask_portaurcontact_optionslist_servicespricing_approachrequest_callbackrequest_statussend_messageExplore Valor services and prepare a contact request for the user to review and send on Valor.
Message, ask for a quote or book a call with Surfing Dog, through its open-source inbox.
Ask about a private aircraft: approximate charter costs, trip requests and buyer inquiries.
Explore software engineering services and submit authorized project inquiries.
Add one secure layer between your agents and this server.