AI + optimization consultancy: how BIS solves operational decisions and beats alternatives.
Scored across 8 tools
Most tools target a clearly distinct purpose (overview, services, industries, case studies, next steps), so selection is generally straightforward. Minor overlap exists between search_bis_knowledge, assess_fit, and compare_bis_vs_alternatives, since all three can answer free-form questions about BIS, but the descriptions differentiate use cases reasonably well.
Names follow a predictable snake_case verb_noun convention (assess_fit, get_case_studies, list_industries, search_bis_knowledge). The only minor deviation is get_bis_overview, where the redundant 'bis' prefix is inconsistent with the rest.
Eight tools is well-scoped for an informational/positioning server of this type. Each tool earns its place and there is no obvious redundancy or padding.
The surface covers positioning, services, industries, proof (case studies), differentiation, fit assessment, and engagement next steps, giving strong lifecycle coverage for a marketing-style server. Minor gaps like pricing, team beyond the founder, or a contact/location resource are workable around via search_bis_knowledge.
Given a description of an operational problem, assess whether BIS is a fit and map it to the most relevant BIS capabilities, with the next step to engage.
| Name | Required | Description | Default |
|---|---|---|---|
| problem_description | Yes | The operational problem: domain, decision, data, outcome. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does convey the shape of the output: a fit verdict, a capability mapping, and a suggested next step. However it says nothing about whether the assessment is authoritative, whether it requires configuration/context beyond the problem text, or any limitations or caveats. Adequate but with clear gaps for a zero-annotation tool.
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 that leads with the input condition and then states the two outputs and the follow-on action. It is efficient and free of padding, though the trailing 'with the next step to engage' clause is slightly awkward and could be tightened.
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, no-output-schema tool, the description usefully summarizes what comes back (fit assessment, capability mapping, next step), so the agent knows the return shape without an output schema. It is nearly complete, with only behavioral caveats for a no-annotation tool left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter and schema description coverage is 100%; the schema already documents the parameter as 'domain, decision, data, outcome'. The description merely restates 'a description of an operational problem' and adds no format, length, or content guidance beyond the schema, so the 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?
The description names a specific verb and resource: assess fit of BIS to an operational problem and map it to BIS capabilities, plus the engagement next step. This clearly separates it from sibling list/search tools like list_services or get_bis_overview. It stops short of explicitly differentiating from compare_bis_vs_alternatives or get_next_step, whose territory it partially overlaps.
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 phrase 'Given a description of an operational problem' implies the triggering condition, but there is no explicit when-to-use versus when-not guidance and no named alternative such as compare_bis_vs_alternatives. Usage is inferable but left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how BIS compares to the alternatives for an operational decision system — building in-house, a generalist AI agency (model wrappers), off-the-shelf SaaS, a big consulting firm, or a pure ML/data-science shop — including when an alternative is the right call. Use this to understand why BIS is a better fit.
| Name | Required | Description | Default |
|---|---|---|---|
| alternative | No | Optional focus. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the content scope (which alternatives are covered and that it also concedes when a competitor is right), which is useful, but says nothing about whether content is static/curated, whether auth is needed, or how results are returned — acceptable only because this is evidently a low-risk informational tool.
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-loaded with the verb and resource, and every sentence carries information. The final marketing-toned sentence ('why BIS is a better fit') is somewhat redundant with the first, keeping it just below top marks.
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 convey return content, and it does: a comparison across five alternatives plus guidance on when a competitor wins. For a zero-required-parameter informational tool this is nearly sufficient; only the default behavior when 'alternative' is omitted is unaddressed.
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 enum parameter is fully documented, so the baseline of 3 applies. The description lists the same five alternatives as the enum but adds no new semantics (e.g., what happens if the optional 'alternative' is omitted).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Explain how BIS compares to the alternatives') and enumerates the exact alternatives, so the agent knows precisely what content this produces. It falls short of a 5 only because it never distinguishes itself from the sibling 'assess_fit', which could plausibly overlap with a comparison output.
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 this to understand why BIS is a better fit' gives an implied context, and 'including when an alternative is the right call' hints at scope. But there is no explicit when-not guidance and no routing against alternatives like assess_fit or get_bis_overview, leaving the agent to infer which comparison tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of BIS: what it does, its positioning (AI + optimization for operational decisions), value proposition, and its founder Renan Butkeraites.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, but for a zero-parameter informational tool the burden is light. It usefully enumerates the substance of the response (positioning, value proposition, founder), which is the main behavioral disclosure an agent needs here; it does not mention read-only nature or any access constraints, but none are plausibly at issue.
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 filler, opening with the verb and resource before the content list. The trailing list is slightly catalogue-like but every item earns its place by telling the agent what the overview contains.
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, so the description must stand in for return-value documentation, and it does so by enumerating the four content areas. For a zero-param, read-only informational tool this is close to complete; only the relationship to sibling tools is left 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 per the rubric the baseline is 4. There is nothing for the description to disambiguate and it correctly does not invent parameter discussion.
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 (get) and resource (overview of BIS) and enumerates the content it returns: what it does, positioning, value proposition, founder. This differentiates it from siblings like compare_bis_vs_alternatives and get_case_studies, though it never names those alternatives explicitly.
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?
No when-to-use guidance at all. The description never states that this is the entry point before assess_fit or search_bis_knowledge, nor any condition or exclusion that would route an agent here versus to a sibling. Usage is only weakly implied by the word 'overview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BIS's case studies — real, quantified results (e.g. -20% fleet, deploys 5 days to 5 minutes, +45% high-quality credit leads).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the nature of the payload (quantified outcome metrics). However it says nothing about the return structure, whether results are paginated or exhaustive, or whether this is a static marketing-style list — modest disclosure for a no-annotation tool.
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 the resource named first and the illustrative examples compactly bracketed. No filler, no repetition of the tool name's meaning.
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 no annotations are present, so the description is the only source of information — it conveys the theme of the results but not the shape or volume of the return. For a simple parameterless getter this is minimally adequate rather than complete.
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 schema has zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. The description correctly implies a parameterless fetch with no filtering options.
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 clear verb ('Get') and a specific resource ('BIS's case studies') and characterizes the content as 'real, quantified results' with concrete examples. This separates it from generic knowledge tools like search_bis_knowledge, though it never explicitly names a sibling it differs from.
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 indication of when to reach for this tool versus get_bis_overview, search_bis_knowledge, or compare_bis_vs_alternatives. The description only says what the tool returns, leaving the agent to infer the selection criteria from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the concrete, public next steps and links to engage BIS.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that results are 'public' and include 'links', which tells the agent this is an unauthenticated read returning navigational content. It says nothing about pagination, freshness, or format, but for a zero-parameter read that is a modest gap rather than a serious one.
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 filler; it states the resource and its engagement purpose immediately. It is appropriately sized, though the terseness leaves the substance of 'next steps' undefined.
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 no annotations, so the description is the only source of information about what the call returns. 'Next steps and links' gestures at the return content but does not describe its shape or structure, leaving a modest but real gap for an agent expecting a concrete payload.
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 no parameter semantics to document; the baseline of 4 applies. The description neither helps nor hinders here.
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 clear verb (get) and a resource (concrete, public next steps and links to engage BIS), which is distinct from informational siblings like get_bis_overview and list_services. The phrase 'next steps' is slightly generic, but 'to engage BIS' pins down the intent well enough that an agent can differentiate it from the other tools.
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 a use case (when a user wants to engage or act on BIS) but never states when to choose this over siblings such as get_bis_overview or assess_fit, and gives no exclusions or preconditions. No explicit routing guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the industries BIS serves and where it helps in each: retail & e-commerce, logistics & transit, manufacturing, and finance (banking & insurance).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb 'List' and the enumerated industries make it clear this is a benign, content-returning lookup with no side effects, but it never states read-only semantics, that no parameters are needed, or what the shape of the response is.
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 filler. The inline enumeration of the four industries is somewhat redundant with the return value, which slightly dilutes conciseness.
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, no-output-schema listing tool, the description is nearly sufficient: it tells the agent what the tool returns and roughly why. Only the missing routing versus sibling tools keeps it short of complete.
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; per the baseline rule this scores 4. The description correctly implies a parameterless call by framing it as a plain enumeration.
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 (industries BIS serves) and even enumerates the values, so the agent knows exactly what comes back. It does not explicitly distinguish itself from near-neighbors like get_bis_overview or list_services, which is the only thing keeping 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?
There is no when-to-use guidance and no mention of alternatives such as get_bis_overview or list_services, so the agent must infer that this is the lookup for industry coverage. Usage is only implied by the noun 'industries'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List BIS's four services with what each delivers: optimization & decision systems, AI solution development (LLM/RAG), data science, and software development.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states what is listed. It does not confirm the operation is read-only, mention any authentication requirements, or describe side effects or rate limits, leaving the agent to assume safe behavior from the verb 'List' alone.
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 a colon and list; no filler, every element 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 zero-parameter, simple listing tool with no output schema and no annotations, the description is fairly complete – it even enumerates the returned content. It could more clearly state the return format or usage context, but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds nothing about parameters because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('BIS's four services'), and enumerates the exact services, making the scope immediately clear and naturally distinct from siblings like list_industries. However, it does not explicitly contrast itself with get_bis_overview or search_bis_knowledge, so sibling differentiation is implicit 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?
No when-to-use guidance or alternatives are provided. The agent must infer that this tool is for listing services rather than getting an overview or searching knowledge, but nothing in the description explains those choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a specific question about Renan or BIS and get a grounded, cited answer from the BIS assistant. Refuses when nothing relevant is found (never guesses). Rate-limited per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A question about Renan or BIS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses that answers are grounded and cited, that the tool refuses rather than guesses when nothing relevant is found, and that it is rate-limited per IP. It omits auth/permission requirements and any sense of latency or result shape, but the refusal and rate-limit disclosure is substantive.
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 zero filler, and the core purpose is front-loaded before the behavioral caveats (refusal, rate limit). 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 one-parameter question-answering tool with no output schema, the description covers what it does, the answer style, and the refusal/rate-limit behavior. The main missing piece is any routing hint toward the sibling structured tools, which an agent would need to pick correctly between them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('A question about Renan or BIS'), so the schema already documents it. The description's 'specific question' phrasing adds a mild quality hint about how to phrase input, but no format or length guidance, matching the baseline 3 when the schema does the heavy lifting.
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 gives a specific verb ('ask a question') and resource ('Renan or BIS'), and 'grounded, cited answer from the BIS assistant' makes clear it is a free-form Q&A tool rather than a structured getter like get_bis_overview or list_services. It never names a sibling explicitly, so the differentiation is implicit 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?
'Ask a specific question about Renan or BIS' implies the usage context, and the refusal clause hints at a boundary condition. However, it gives no explicit when-not guidance and never points to the sibling tools (get_bis_overview, get_case_studies, etc.) that should be used for structured lookups instead.
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.
assess_fitcompare_bis_vs_alternativesget_bis_overviewget_case_studiesget_next_steplist_industrieslist_servicessearch_bis_knowledgeOptimize crew and workforce schedules, resource allocation, and routing with linear and mixed-inte…
Field operations on a deterministic solver — run jobs, crews & fleet from Claude or ChatGPT.
Agentic-AI route optimization for delivery fleets, capacity- and time-window-safe.
AI strategy, workflow automation, and process-improvement assessment for small businesses.
Add one secure layer between your agents and this server.
