boondmanager-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.14.0
Disambiguation4/5
Most tools are clearly separated by entity and action, e.g., boond_candidates_create vs boond_candidates_search. However, there are a few overlapping pairs like boond_resources_timesheets vs boond_resources_times_reports (both retrieve timesheets) and boond_planning_absences_search vs boond_absences_search, which create mild ambiguity.
Naming Consistency4/5
The naming follows a consistent pattern: boond_<entity>_<action> in snake_case. The workflow tools break this pattern but are a distinct category. Minor inconsistencies exist, such as using singular vs plural (e.g., boond_absences_create vs boond_contact_create? Actually boond_contacts_create is plural) but overall the pattern is clear.
Tool Count2/5
With 180 tools, the server is extremely heavy. While the domain (BoondManager CRM) is broad, many tools could be consolidated (e.g., sub-entity getters like boond_candidates_actions could be tabs of boond_candidates_get). This volume will likely overwhelm an agent's tool selection and context window.
Completeness4/5
The server covers a wide range of entities (candidates, companies, projects, resources, etc.) with create, read, update, delete, and search operations for most. Some entities lack full CRUD (e.g., deliveries only have create and get; payments no update/delete), but the coverage is comprehensive for a CRM/ERP surface.
Average 3.8/5 across 180 of 180 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 14 of 14 community issues answered or closed in the last 6 months
- 80 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds return format and pagination, but it contradicts the schema with wrong defaults (pageSize default 20/max 100 vs schema default 30/max 500) and omits the 'fields' parameter, reducing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and informative, but the Args section redundantly repeats the schema definitions and includes errors. The description is not overly long, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four optional parameters and an output schema, the description should cover all parameters and usage context. It omits 'fields', includes incorrect pagination limits, and offers no guidance relative to sibling tools, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 provides inconsistent default values for page/pageSize and fails to mention the 'fields' parameter. This adds no value and introduces contradictions that can mislead the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches poles in BoondManager by keywords with pagination, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling tool boond_poles_get, so it is clear but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this search tool versus alternatives like boond_poles_get. The description only restates the function without any context on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds that it returns a list with ID, name, and details, but discloses no additional behavioral traits like authentication needs or rate limits. The conflicting pageSize limit (100 vs schema's 500) introduces a minor transparency issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description has a clear summary and structured Args/Returns sections, but the Args list redundant with the schema and contains incorrect values. Not as concise as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits the 'fields' projection parameter and provides wrong pagination limits, leaving the agent with incomplete and partially incorrect contextual information. While the output schema and annotations help, the description's errors make it insufficient for fully understanding the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters, so baseline is 3. However, the description omits the 'fields' parameter entirely and provides contradictory defaults for pageSize (default 20/max 100 vs schema's default 30/max 500). This actively misleads the agent instead of adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches user accounts in BoondManager by keywords with pagination. The verb 'Recherche' and resource 'comptes utilisateurs' make the purpose unambiguous and distinct from siblings like boond_accounts_get, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as boond_accounts_get for single-account lookups. It lacks any explicit exclusions or context on preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false, idempotentHint=false). The description adds no behavioral context beyond stating it creates a request, such as side effects, required permissions, or what happens on success. No contradiction with annotations, but no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of unnecessary words. It states the core action and the primary object without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema, the description is extremely minimal. It gives no indication of what the tool returns (no output schema), does not explain any side effects, and offers no usage context for a create operation. The agent is left without critical information for a complex 9-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 9 parameters (100% coverage), so the baseline is 3. The description only mentions 'absencesPeriods' without adding detail, and it does not enhance understanding of any parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Boond absence request, using the specific verb 'Cree' and the resource 'demande d'absence'. It is unambiguous and aligns with the tool name, but it does not explicitly differentiate from sibling tools like boond_absences_update or boond_absences_delete, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as boond_absences_update or boond_absences_search. It does not mention prerequisites, constraints, or any context for when a create operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context such as return format, error behavior, authentication requirements, or data sensitivity. It merely repeats the tool's purpose without value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with a one-sentence purpose and an args/returns structure. However, the 'Returns' line simply repeats the purpose, and the 'Args' block duplicates the schema, introducing minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one parameter and good annotations, the description is reasonably complete. However, without an output schema, it fails to clarify what 'administrative data' includes, which could lead to ambiguity when choosing among similar candidate endpoints. Slightly more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single 'id' parameter (string, numeric pattern, unique identifier). The description's 'ID du candidat' adds only a slight clarification that it refers to a candidate ID, which is already obvious from the tool name. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves administrative data for a candidate using a specific verb ('récupère') and resource. However, it does not distinguish this from sibling tools like boond_candidates_information or boond_candidates_technical_data beyond the word 'administrative', which is a clear but unstated differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The intended use is only implied by the name/title, and the description offers no exclusions, prerequisites, or comparisons to sibling candidate endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond the search action, such as pagination behavior, result limits, or projection handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and free of fluff. However, it is so sparse that it borders on under-specification, which is slightly penalized here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 optional parameters, no output schema, and many sibling search tools, the description provides insufficient context to understand the tool's full capabilities or when to use it. It does not explain result formats, pagination defaults, or alternatives, making it inadequate for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions, providing 100% coverage. The tool description adds no parameter-level detail, so the schema carries the full burden. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recherche des factures fournisseur dans BoondManager' clearly states the action (search) and the resource (provider invoices). The 'fournisseur' qualifier distinguishes it from the general invoice search, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus related tools like boond_invoices_search or boond_provider_invoices_get. There is no mention of filters, scope, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows it is a write operation but not idempotent or destructive. The description does not disclose any side effects, required permissions, or validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose. It is concise, front-loaded, and contains no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 optional parameters and no output schema. The description provides no information about required relationships (e.g., need for companyId or projectId), what constitutes a valid purchase, or what the tool returns upon success. The description is too minimal for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter described (e.g., 'Titre de l'achat/sous-traitance', 'ID de la société fournisseur'). The description does not add additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new purchase/subcontracting in BoondManager, with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like boond_purchases_search or boond_purchases_get, though the action 'create' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, no exclusions, and no context about prerequisites or use cases. It simply restates the creation action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds no additional behavioral context such as filtering, pagination, or authorization requirements, only repeating the retrieval purpose and return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. It follows a clear Args/Returns structure, though it repeats 'feuilles de temps' multiple times.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description is adequate but lacks clarity on how it differs from the sibling 'boond_resources_timesheets' and does not detail the return structure beyond 'list of timesheets'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'id' parameter fully described in the schema as a numeric BoondManager entity identifier. The description's 'ID de la ressource' adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the timesheets of a resource (Récupère les feuilles de temps d'une ressource), specifying the verb and resource. However, it doesn't differentiate from the similarly named sibling 'boond_resources_timesheets', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'boond_resources_timesheets' or 'boond_timesheets_search'. It only describes the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds pagination context and a return summary, but it misstates the pageSize contract (default 20, max 100 vs schema's default 30, max 500), which is actively misleading behavioral disclosure for an agent relying on the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The format is compact — purpose sentence, Args list, Returns line — and easy to scan. However, the Args list duplicates schema content with an error, and the omission of 'fields' makes it inconsistent rather than tightly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and read-only annotations, the description does not need to explain return values in depth, and it gives a reasonable summary of results. The main gaps are the incorrect pageSize values and the omission of the fields projection parameter, which reduce completeness despite good underlying structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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's Args block adds no value beyond the schema and introduces an incorrect default/max for pageSize. It also omits the 'fields' projection parameter entirely, leaving the parameter documentation incomplete and partially inaccurate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (recherche) and resource (todolists in BoondManager) with a clear scope (by keywords, with pagination). It is clear and specific, but it does not explicitly differentiate from sibling boond_todolists_get or name alternatives, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — this is the keyword-search entry point for todolists with pagination. However, it provides no when-to-use vs alternatives guidance, no exclusions, and does not mention that boond_todolists_get is the appropriate tool for retrieving a single known todolist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds return-value information (list with ID, name, main details) and pagination, but does not disclose additional behavioral constraints beyond existing annotation coverage. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but the Args section is redundant with the schema and contains factual errors about pagination limits. The structure is clear, but inaccuracies undermine its value, so it does not earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and annotations are present, so a brief description would suffice. However, the inconsistent pageSize defaults/max and omission of the 'fields' parameter create confusion, leaving the tool less complete than the bare schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, but the description's Args section misstates pageSize (default 20, max 100 vs schema's default 30, max 500), omits the 'fields' parameter entirely, and adds no meaningful detail beyond what schema already provides. This actively harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches agencies in BoondManager by keywords with pagination, using a specific verb (Rechercher) and resource (agences). It distinguishes itself from siblings like boond_agencies_get, which presumably fetches a single agency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword-based search but does not explicitly mention when to prefer this over boond_agencies_get or mention exclusions. No alternative tools are named, so guidelines remain implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, idempotent, open-world, and non-destructive behavior. The description adds pagination details but these are contradictory to the input schema: it states pageSize default/max as 20/100 while the schema declares 30/500. This is misleading and reduces transparency. It also omits the 'fields' parameter entirely, giving an incomplete behavioral view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a clear summary, but the Args section largely duplicates schema information and includes an inaccuracy. The Returns line is helpful but the overall structure could be tighter without the redundant parameter listing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations, the description could rely on those, but it still provides inconsistent pagination info and omits 'fields'. It also does not clarify how this search tool relates to boond_business_units_get. These gaps make it incomplete for an agent to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value for 'keywords' with examples (nom, email, compétences) and clarifies pagination defaults, but it contains incorrect pageSize values and completely omits the 'fields' parameter. Thus it neither fully compensates nor significantly degrades clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a keyword-based search of business units in BoondManager with pagination. This distinguishes it from the sibling tool boond_business_units_get (which presumably retrieves a single business unit) and other entity-specific searches like boond_opportunities_search or boond_resources_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the existence of boond_business_units_get or any other search tools, nor does it state when not to use this tool. Though the name implies search, there is no explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the core action of creating a contract, which aligns with the annotations (readOnlyHint false). However, it does not disclose any side effects, requirements (e.g., existing resource), or error conditions, leaving the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information, making it easy to parse. It is appropriately brief for the tool's straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description lacks critical context about required fields in practice (e.g., resourceId), the return value (no output schema), and how this fits into the broader BoondManager workflow. The tool has 5 optional-looking parameters, which may mislead the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 5 parameters (100% coverage). The tool description adds no additional meaning about parameter usage, such as which parameters are typically required or how they interact. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new employment contract in BoondManager, using the specific verb 'Crée' and the resource 'contrat de travail'. This distinguishes it from related tools like boond_contracts_get, which retrieves contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as boond_contracts_get for reading contracts or other create tools for different entities. There is no mention of prerequisites or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns a list, consistent with the readOnlyHint annotation, but it contains a significant inaccuracy: it says pageSize max is 100 while the schema allows up to 500, and default is 20 while schema says 30. This misrepresents actual tool behavior and undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably short with a clear Args/Returns structure, but the parameter lines are redundant with the schema and contain incorrect values. Since every sentence should add value, the inaccuracies mean the text does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the schema and annotations are rich, the description is incomplete: it ignores the 'fields' parameter and provides wrong pagination limits. For a straightforward search tool, the description should correctly summarize all parameters and behavior, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 lists only 3 of 4 parameters, omitting 'fields', and misstates the defaults/max for page and pageSize. It adds no new meaning beyond the schema and even introduces contradictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for discussion threads in BoondManager by keywords with pagination, which is a specific verb+resource combination. It distinguishes from siblings like boond_threads_get by indicating this is for searching, not retrieving a single thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('par mots-clés' and 'paginated search'), but it does not explicitly mention alternatives or exclusionary conditions. It lacks explicit guidance such as 'use boond_threads_get when the thread ID is known'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so there is no contradiction. However, the description adds no behavioral context beyond the purpose, such as filters, pagination, sorting, or scope of invoices included. It only mentions the return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with a clear structure: a one-line purpose, an Args block, and a Returns line. Every part is necessary and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation with robust annotations, the description is minimally acceptable. It states purpose and return type, but lacks usage guidance and clarification of invoice scope. Given many related invoice tools, the absence of alternative pointers leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the id parameter ('Identifiant unique de l'entité BoondManager'). The description adds 'ID de la société', which clarifies the role but not any new semantic meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Récupère les factures d'une société' (retrieves invoices of a company). It is clearly distinguished from global invoice search/get tools, though it doesn't explicitly differentiate from provider invoices (boond_companies_provider_invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus boond_invoices_search, boond_invoices_get, or boond_contacts_invoices, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden of disclosing behavioral traits. It only says 'creates' — the bare minimum. It does not mention side effects, required permissions, idempotency, or what happens on success/failure. This lack of depth is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core purpose and is easy to parse. While it is brief, it does not waste words; for a simple create action, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, 4 required, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns, any prerequisites for using it (e.g., existing companies/contacts), or how the many optional parameters interact. The context is too sparse for an agent to confidently invoke this tool in a nontrivial workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters. The description adds minimal semantic value by naming three related fields (resource, providerCompany, providerContact), but these names do not exactly match the schema parameters (resourceId, companyId, contactId), and no additional meaning is provided beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Crée' = creates) on a specific resource ('facture fournisseur Boond' = Boond provider invoice), and names key fields (resource, providerCompany, providerContact). This clearly distinguishes it from sibling tools like boond_provider_invoices_search and boond_provider_invoices_get, which handle querying rather than creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. It does not mention related tools (e.g., boond_invoices_create for regular invoices), nor does it state any prerequisites or scenarios where this tool is preferred. The user is left guessing about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes pagination details and a return line, but the values for pageSize (default 20, max 100) contradict the input schema (default 30, max 500). It also fails to mention the 'fields' projection parameter, providing incomplete and misleading behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose, but the Args section repeats schema information and introduces inaccuracies. It could be more concise and accurate by removing incorrect defaults and omissions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotated read-only operation and rich schema, the description should complement rather than contradict structured data. The pagination mismatch and missing 'fields' parameter make it incomplete and potentially misleading for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description inaccurately documents pageSize (default 20/max 100 vs schema's 30/500) and omits the 'fields' parameter entirely. This adds negative value by conflicting with the schema and failing to describe a valid parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching for webhooks in BoondManager by keywords with pagination. It uses a specific verb and resource, and the resource (webhooks) distinguishes it from sibling search tools for candidates, contacts, resources, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool (when searching for webhooks) but does not explicitly mention alternatives or exclusions, such as using boond_webhooks_get for retrieving a specific webhook. The usage context is inferable but not clearly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds little beyond stating it returns a list. No additional behavioral context such as pagination, filtering, or ordering is provided, but it does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with an Args/Returns format, making it easy to parse. However, some content (like 'Args: - id') duplicates schema information, and the conciseness is adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and good annotations, the description gives a high-level return type but lacks details on pagination, sorting, or potential empty results. Without an output schema, this could be more informative, but it is sufficient for a basic retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the input schema with a pattern and explanation. The tool description merely repeats 'ID de la société', adding no new meaning beyond the schema, so it aligns with the 100% schema coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves commercial opportunities for a company, using the specific verb 'Récupère' and the resource 'opportunités commerciales d'une société'. It is unambiguous, though it does not explicitly differentiate from sibling tools like boond_contacts_opportunities or boond_opportunities_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any exclusions or compare to related tools such as boond_opportunities_search or boond_opportunities_get, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that it returns complete JSON data and supports an optional tab parameter, but it doesn't disclose error behaviors, authentication needs, or default tab behavior. This is acceptable given the annotations but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, followed by a clear Args/Returns structure. It has no wasted words, though the parameter list duplicates the schema slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with two parameters, strong annotations, and no output schema, the description adequately covers the purpose, parameters, and return format. It doesn't specify edge cases or what 'complete' means, but the low complexity makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both id and tab, including patterns and allowed values. The description repeats these details without adding new semantics such as default values, examples, or behavioral side-effects, so it stays at the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Récupère les informations détaillées') and the resource ('opportunité') identified by ID, with an optional tab parameter. It distinguishes from search/create/update/delete siblings but does not address the existence of boond_opportunities_information, which could be confused as the same operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like boond_opportunities_search. The phrase 'par son ID' implies you must already have an ID, but it doesn't state that search should be used when the ID is unknown, nor does it mention any prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds only that it returns a list of matching orders, which is obvious. There is no additional behavioral context such as result ordering, exact-match filtering, or potential data limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured with a one-line summary, an Args block, and a Returns line. It is front-loaded and wastes few words. However, the Args block is slightly redundant with the schema and omits one parameter, but this does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no required parameters, comprehensive schema coverage, and an output schema, so the description does not need to explain return formats. However, it fails to mention the 'fields' parameter and does not position this tool relative to other order-related tools. It is minimally adequate but leaves gaps for an agent trying to understand all capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args section largely duplicates the schema with brief explanations. However, it omits the 'fields' parameter entirely, which the schema documents for projection. It does not add meaningful new semantics beyond the schema, and the omission could mislead an agent relying solely on the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recherche') and identifies the resource ('bons de commande') with filters by company and project. It clearly states what the tool does, but does not explicitly distinguish it from sibling tools like boond_companies_orders or boond_projects_orders, which also deal with orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is the general search tool compared to entity-specific order lists, nor does it state any prerequisites or exclusions. Sibling tools are not referenced, so the agent gets no help in choosing among similar search/list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it returns a list of deliveries but does not disclose pagination, ordering, or the exact handling of 'groupements' beyond the initial mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by Args and Returns sections. It avoids unnecessary words, though the mention of 'groupements' in the purpose but not in the Returns is a minor structural gap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description provides the basic return expectation ('Liste des livraisons'). However, the initial mention of 'groupements' is not reflected in the Returns, and there is no detail on whether the response is paginated or includes nested data. Overall, adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter. The description clarifies that 'id' is the project ID, adding slight context beyond the schema's generic 'entity' wording, but this is largely inferable from the tool name. No significant additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves deliveries (CRA) and associated groupings for a project, using the specific verb 'Récupère'. It distinguishes from sibling tools by scoping to project deliveries, though it does not explicitly name alternatives as in the calibration example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of preferred contexts, exclusions, or comparisons to sibling tools like boond_deliveries_get or boond_projects_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns general project data with specific fields, but provides no additional behavioral context such as error behavior, response format, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by structured Args and Returns sections. Minor imperfections include the trailing '...' in the field list and the Args section merely restating the schema parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required param, read-only), and the description adequately explains what it returns. However, the ambiguity with boond_projects_get and the lack of any distinction between the two tools makes the description incomplete for correct tool selection in the broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description. The description adds that the 'id' is the project ID, which is slightly more context than the schema's 'entité BoondManager', but it does not compensate for any missing information since the schema is already comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves general project information with examples (client, dates, état, description, responsable), using the verb 'Récupère'. However, it does not distinguish this from the sibling tool boond_projects_get, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like boond_projects_get or boond_projects_search. The description gives no context or exclusions, leaving the agent to guess which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one meaningful behavioral detail: "Returns: Données du/de la ressource créé(e) avec son ID." This explains the return value, which is not covered by the annotations (readOnlyHint=false etc.). However, it does not disclose side effects, permissions, or validation behavior beyond the schema. With annotations present but minimal, this is a reasonable middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: one sentence for purpose and one for the return value. It is front-loaded and contains no filler. Every word adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the output schema exists and the description mentions the return wrapper, the description lacks broader context. It does not explain what a 'ressource' is in BoondManager, when to use this tool versus candiate/contact creation, or what side effects (e.g., status changes) occur. For a 9-parameter creation tool with many siblings, this minimal description is insufficient for an agent to fully understand its place.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The description adds no parameter-specific information beyond what the schema provides. For example, the schema already defines fields like firstName and lastName as required. The description could have compensated for terse field labels (e.g., 'Ville'), but it does not, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: "Crée un(e) nouvel(le) ressource dans BoondManager." This provides a specific verb (create), resource (ressource), and system (BoondManager). However, it does not explicitly distinguish this tool from sibling create tools such as boond_candidates_create or boond_contacts_create, so it lacks a small amount of differentiation clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, required fields, or situations where creation is appropriate. Given the large sibling list with similar create operations, this absence makes it harder for an agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds basic behavioral details (returns list with ID, name, main details, pagination), but does not disclose any additional traits like rate limits or special response behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear one-sentence overview, a compact Args list, and a Returns line. It is front-loaded and not excessively verbose, but includes inaccuracies (incorrect pageSize defaults/max) and omits the 'fields' parameter, which slightly detracts from the structure's reliability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, an output schema, and rich sibling context, but the description is incomplete: it omits the 'fields' parameter, does not mention sibling tools or when to use this search, and contains contradictory pagination details. These gaps could lead an agent to misuse the tool or choose the wrong sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all parameters, so the baseline is 3. However, the description's Args section introduces inaccuracies: it states pageSize default is 20 and max is 100, while the schema indicates default 30 and max 500. It also completely omits the 'fields' projection parameter, which is documented in the schema. Thus, the description actually reduces clarity rather than adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for roles ('Recherche des rôles dans BoondManager par mots-clés avec pagination'), specifying the resource (rôles), action (recherche), and scope (mots-clés, pagination). It is distinct from siblings like boond_roles_get, which is likely for fetching a single role, and other entity-specific search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as boond_roles_get for retrieving a specific role or other search tools for different entities. It simply states what the tool does without exclusions or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint: false) but provide no other behavioral context. The description adds no behavioral traits such as idempotency, error conditions, or side effects. It only repeats the create action without disclosing what happens on duplicates or what response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains zero wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not specify required fields, optional fields, or return behavior. Although the schema lists parameters, the description does not clarify that only resourceId and term are required, nor what the created timesheet will contain. With no output schema, more contextual guidance is expected but absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates ('Crée') a monthly timesheet linked to a resource, which is a specific verb+resource+scope. It distinguishes from sibling tools like boond_timesheets_search and boond_timesheets_get, and there is no other create-timesheet sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contrast with search/get operations. The usage context must be inferred purely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description introduces inaccurate behavioral details: it states pageSize has a default of 20 and max of 100, whereas the schema specifies default 30 and max 500. This could mislead an agent about response limits. It also omits the 'fields' projection parameter. While annotations cover read-only and idempotent behavior, the description adds misleading pagination info, which is a transparency failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, well-structured with an overview, args list, and returns statement. It is front-loaded with the core purpose. However, it includes redundant parameter details that conflict with the schema, which slightly reduces efficiency, but the overall format remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the schema provides full parameter descriptions and an output schema exists, the description could be minimal, but it still misses the 'fields' parameter and provides incorrect pagination bounds. This creates an incomplete and slightly inconsistent picture, though the core functionality is adequately conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description does not add meaningful value beyond the schema. It repeats keywords and page defaults mostly as-is, but gives conflicting pageSize limits and completely omits the 'fields' parameter. The description's incorrect parameter metadata actively harms understanding rather than clarifying it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches calendars in BoondManager by keywords with pagination, and specifies it returns a list with IDs, names, and main details. This is a distinct search operation compared to the sibling tool boond_calendars_get, which retrieves a single calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for keyword-based searches and mentions pagination, but it does not explicitly state when to use this tool versus boond_calendars_get or any other alternative. There are no exclusions or alternative tool references, leaving usage to be inferred from the name and generic search behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds that the operation returns a list, but doesn't disclose additional behavioral nuances (e.g., whether it includes both purchases and subcontracting, pagination, or filtering). No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main action, and has a clear structure separating arguments and return value. It could omit the Args block since the schema already documents the parameter, but it's not redundant enough to be a problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a minimal return type ('Liste des achats'), but doesn't specify what elements the list contains, whether it includes subcontracting as mentioned in the title, or any limitations. Given the low complexity, this is adequate but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the meaning that the id refers to a company ('ID de la société'), which is more specific than the schema's generic 'Identifiant unique de l'entité BoondManager'. This clarifies the parameter's role beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves purchases/subcontracting for a company ('Récupère les achats/sous-traitance d'une société'). It uses a specific verb and resource, but doesn't explicitly distinguish it from sibling tools like boond_companies_provider_invoices or boond_companies_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states the function and parameter, without any contextual hints about use cases, exclusions, or distinguishing features relative to other company-related retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds that the tool returns both personal and professional data, which is some behavioral context beyond the annotations. However, it does not disclose any other behavioral traits such as error handling or access restrictions, which is acceptable for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and well-structured with Args and Returns sections. Every sentence contributes meaningful information, and there is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation with no output schema, the description covers the basic return contents (personal and professional data) with examples. However, it fails to clarify how this tool differs from the similarly named boond_contacts_get, and the return structure is left vague. Given the availability of rich annotations, the description is minimally acceptable but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description of the only parameter (id) with a clear pattern and explanation. The description repeats 'ID du contact' without adding new meaning, so it does not enhance the schema's semantic coverage. Baseline 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves general contact information, listing example fields (coordonnées, société, fonction, tags). It uses a specific verb and resource, making the purpose obvious. However, it does not distinguish itself from the sibling tool boond_contacts_get, which likely serves a similar or overlapping role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description gives no context, exclusions, or mention of related tools like boond_contacts_get or boond_contacts_search, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds no behavioral context beyond what is implied by the annotations, such as pagination behavior or authorization requirements. It does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and free of unnecessary information. It effectively communicates the tool's purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and annotations, the description is minimally viable but lacks any guidance on usage scenarios or differentiation from sibling tools. The presence of an output schema and annotations relieves the description of explaining return values or safety, but it does not leverage the opportunity to add strategic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The description's mention of filters (societe, projet, periode) aligns with schema parameters but adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches invoices ('Recherche des factures') and identifies key filters (company, project, period). It is concise and uses a specific verb, but does not distinguish itself from similar invoice-related tools like boond_companies_invoices or boond_invoices_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to use boond_invoices_get for a specific invoice or boond_companies_invoices for company-specific invoices. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds some context by listing example data fields, but does not disclose additional traits such as required permissions, potential errors, or any limitations. This is minimal added value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the purpose, followed by structured Args and Returns sections. Every word is functional with no filler or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description provides enough to understand its basic function. However, it lacks an output schema and the return description is vague ('Données générales'), while the ellipsis suggests incomplete information. It also does not clarify the distinction from boond_opportunities_get, leaving a contextual gap for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter with pattern and description, achieving 100% coverage. The description merely repeats 'ID de l'opportunité' without adding new meaning. Since the schema does the heavy lifting, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves general information about an opportunity (client, dates, amount, probability, status), using a specific verb and resource. However, it does not differentiate itself from the sibling tool 'boond_opportunities_get', which may serve a similar or overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or how it differs from boond_opportunities_get or boond_opportunities_search. The agent is left without context to choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context that types/states come from the dictionary and the default perimeter behavior, but it does not disclose output format, pagination specifics, or potential performance characteristics. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. It uses bullet-like lists of filters and conditions without excessive prose. The 'Returns' line is short but functional. No wasted words, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 24 parameters, no output schema, and the description's 'Returns: Données de reporting' is too vague to help an agent understand the response structure. It does not explain how the report is organized (e.g., by resource or by period), how indicators relate, or how pagination works. Given the complexity, the description is incomplete for effective invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a note about states/types being integer IDs from boond_application_dictionary, which is also mentioned in the schema. It does not provide significant new semantics beyond what the schema already offers, so no higher score is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is for resource reporting with examples of metrics (taux d'occupation, CA, productivité), making the purpose clear. It lists key filters and mentions scope, which helps distinguish it from other reporting tools, though it does not explicitly compare itself to sibling tools like boond_reporting_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful guideline: without a perimeter filter, the report covers the entire authorized perimeter. It also lists the main filter categories (perimeter, period, reportingCategory, etc.) but does not explicitly state when to choose this tool over alternatives such as boond_reporting_companies or boond_reporting_synthesis. There is no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile. The description adds a minimal 'Returns: Liste des avantages correspondants' but does not disclose pagination behavior, response format details, or any rate limits. It adds some context beyond annotations but not significant behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: a one-sentence summary, an Args list, and a Returns line. The Args list is redundant with the schema, but it is organized and easy to scan. It earns high marks for clarity, though it could trim redundant parameter repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with comprehensive schema coverage, the description is adequate but not complete. There is no output schema, and the Returns line is vague ('Liste des avantages correspondants') without specifying the structure or whether standard summary fields are included. The schema's 'fields' description hints at a 'standard summary', but the description itself does not clarify return expectations. Given the low complexity, a 3 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the keywords, resourceId, and pagination params but adds no new meaning beyond the schema. It omits the 'fields' parameter entirely, but since the schema fully documents it, the description does not need to compensate. The redundancy means no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for benefits (avantages) in BoondManager, with examples (tickets restaurant, mutuelle, véhicule, primes) and an optional resource filter. This is a specific verb+resource+scope that distinguishes it from sibling tools like boond_advantages_get (a getter) and boond_resources_advantages (resource-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this search tool versus alternatives. The sibling list includes boond_resources_advantages and boond_advantages_get, but the description does not mention when to prefer this tool or any exclusion criteria. The 'optional resource filter' hint is implicit usage, not explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the return note 'Returns: Données du/de la candidat créé(e) avec son ID', which is useful context beyond annotations. It does not mention side effects or prerequisites, but annotations already indicate a non-read-only operation, so the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the main purpose and a short line for the return value. No wasted words, front-loaded with action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema and presence of an output schema, the description is adequately complete. It covers what the tool does and what it returns, though it could mention that only firstName and lastName are required or distinguish from update/delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 10 parameters. The description does not add any parameter-specific meaning, but baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crée un(e) nouvel(le) candidat dans BoondManager', specifying the action (create) and resource (candidate). It distinguishes from sibling tools like boond_candidates_update or boond_candidates_delete through the verb 'create', though it is close to restating the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that update should be used for existing candidates or search for finding candidates. The context is only implied by the action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a list of return fields (contact info, address, photo, tags, source) which is useful context, but does not go beyond annotations with additional behavioral details such as response format or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence of purpose and a short Args/Returns block. Every line serves a purpose, and it is well-structured with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only endpoint with a single parameter and strong annotations, the description adequately covers the purpose, parameter, and a general overview of return data including example fields. Although there is no output schema, the description provides enough context for an agent to understand what the tool returns, though more detail on response structure could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a detailed description for 'id' as a numeric unique identifier. The description's Args section merely repeats 'id' without adding new meaning, so the schema already carries the semantic load. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves general candidate information, listing specific fields like coordonnées, adresse, état civil, photo, tags, and source. The verb 'Récupère' and resource 'candidat' make the action specific, but it does not explicitly distinguish from sibling tools such as boond_candidates_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling alternatives like boond_candidates_get, boond_candidates_administrative, or boond_candidates_technical_data. It only states what the tool does without any context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety traits. The description's 'Récupère' aligns with annotations but adds no additional behavioral context such as permissions, rate limits, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using a clear Args/Returns structure. Every sentence conveys necessary information without waste, and the field examples provide useful detail in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and strong annotations, the description is mostly complete: it states purpose, lists expected field categories, and mentions return data. However, it does not detail the exact response structure or any edge-case behavior, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter fully documented as a unique numeric entity identifier. The description's 'id (string): ID de la société' is redundant and adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves general company information, listing specific examples (coordonnées, SIRET, site web, secteur, taille, tags). It uses a specific verb+resource structure, but does not explicitly distinguish itself from sibling tool boond_companies_get, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of exclusions or prerequisites, and no reference to sibling tools. The description only states what it does and its parameters, providing no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the types of actions returned (calls, emails, meetings, notes) but does not disclose other behavioral aspects such as pagination, sorting, or potential absence of certain action types. It is consistent with the annotations, adding moderate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main purpose in the first sentence. It includes structured Args and Returns sections. However, the Returns section ('Liste des actions liées à l'opportunité') is redundant with the opening sentence, and the argument description could be incorporated more tightly. Overall, it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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's 'Returns: Liste des actions liées à l'opportunité' is the only return-value information. It does not describe the structure of each action, whether the list is paginated, or if any filtering is applied. Given the tool's simplicity and the clear input schema, this is adequate but not complete; an agent might need more detail on the returned objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'id' with type, pattern, and a generic description. The tool description adds 'ID de l'opportunité', which clarifies that the id refers to an opportunity, but this is easily inferred from the tool name. Since schema coverage is 100%, the description adds minimal extra value beyond the existing schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Récupère les actions (appels, emails, RDV, notes) associées à une opportunité.' It specifies the verb (récupère), the resource (actions), and the scope (associées à une opportunité), distinguishing it from generic action search tools like boond_actions_search and from action tools for other entities like boond_contacts_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or direct the agent to other tools (e.g., boond_actions_search for searching all actions, or boond_opportunities_positionings for positioning). The use case is implied by the name and scope, but no comparative guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns the absence planning and provides a global view, but no further behavioral details (e.g., pagination behavior, filtering caveats) are offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and the main action front-loaded. The 'Returns' line is slightly redundant with the first sentence but does not introduce significant waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool without an output schema, the description gives the basic purpose and states that it returns the planning, but lacks detail on result structure or available fields. Given the strong annotations and full schema coverage, the gaps are moderate but leave room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters (page, fields, keywords, pageSize) have complete descriptions in the input schema, achieving 100% schema coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recherche') and identifies the resource as the absence planning in BoondManager, further clarifying a 'global view of planned absences'. This clearly conveys the tool's function and scope, though it does not explicitly differentiate it from the sibling tool boond_absences_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case via 'vue globale des absences prévues' (global view of planned absences), suggesting it is meant for viewing upcoming absence schedules. However, it does not explicitly state when to use this tool over alternatives like boond_absences_search or absence report tools, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint, so the safety profile is clear. The description adds pagination and return info, but no further behavioral traits such as rate limits or scope limitations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, structured with Args and Returns, and front-loaded with the main purpose. The inaccuracies reduce its value, but structurally it's clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage and helpful annotations, the description's incorrect defaults and missing 'fields' parameter make it incomplete and potentially misleading. An agent relying on the description might pass wrong pageSize values or overlook the fields projection option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description omits the 'fields' parameter entirely and states incorrect defaults for pageSize (says 20/max 100, while schema says default 30/max 500). This actively misleads the agent and undermines the schema's accuracy. With 100% schema coverage, the description should align with the schema or add value; instead it contradicts it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches products by keywords with pagination, using a specific verb and resource. It distinguishes from sibling tools like boond_products_get (which retrieves a specific product) by emphasizing keyword-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (search products by keywords) and includes pagination context. It doesn't explicitly list exclusions or alternatives, but the 'search' role is clear, and sibling tools like get/create/update/delete are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only that it returns a list, without disclosing behaviors like whether subcontracting is included, pagination, or authentication requirements. It is consistent with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with an Args/Returns format. Every sentence serves a purpose. A minor inconsistency between the tool's stated scope ('achats et sous-traitance') and the return value ('Liste des achats') prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, single-parameter tool with strong annotations, the description adequately covers purpose, input, and output. It lacks additional context such as pagination or clarification of whether subcontracting is included in the returned list, but overall it is sufficient for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a generic description of id as 'Identifiant unique de l'entité BoondManager (numérique)'. The description adds project-specific meaning by calling it 'ID du projet', which helps agents understand the parameter's role beyond the schema. No further syntax or formatting details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère') and resource ('achats et sous-traitance associés à un projet'), clearly indicating it retrieves project-related purchases. However, it doesn't explicitly distinguish from sibling tools like boond_projects_orders or boond_purchases_search, and the return value mentions only 'achats' despite the title including 'sous-traitance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only implies the context through 'associés à un projet' but does not mention any exclusions, alternatives, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Récupère' is consistent with those flags. The description adds minimal behavioral context beyond the annotations, such as noting the data is personal/administrative, but it does not discuss authentication, error behavior, or output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a clear opening sentence followed by concise Args and Returns sections. Every sentence contributes useful information, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only resource retrieval with one parameter and strong annotation coverage, the description is largely complete. It clearly indicates the kind of data returned, though the exact response structure is somewhat vague due to the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'id' parameter with a more detailed description and pattern. The description's 'id (string): ID de la ressource' adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Récupère') and the target ('informations générales d'une ressource'), and it enumerates example fields (coordonnées, adresse, état civil, photo, tags, manager). However, it does not explicitly distinguish this from overlapping sibling tools like boond_resources_get or boond_resources_administrative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as boond_resources_get, boond_resources_administrative, or boond_resources_technical_data. The description only states what the tool does without any contextual use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe read nature is covered. The description adds only that it returns a list, which is already evident from 'Récupère' and the Returns line. It does not disclose any additional behavioral traits such as pagination, ordering, or potential empty results beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with a clear purpose sentence. The Args/Returns section is structured and minimal. Minor redundancy: 'Returns: Liste des positionnements' restates what 'Récupère' already implies, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one well-documented parameter and full annotation coverage, the description provides enough information. It explains the resource type and return format, though it could note that the list might be filtered/detail-free. No output schema exists, but the return list is described sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already thoroughly documents the 'id' parameter with type, pattern, and description. The description merely repeats the parameter name and type, adding no extra semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' and names the exact resource: 'les positionnements (placements sur des opportunités/projets) d'un candidat'. It disambiguates from sibling tools like boond_candidates_get (gets candidate info) and boond_positionings_get (general positionings) by scoping to a specific candidate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a candidate's positionings) but does not explicitly contrast with alternatives like boond_positionings_search or boond_candidates_get. There is no direct 'use this when' guidance, only the inherent purpose from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, establishing this as a write, non-idempotent operation. The description adds the return value detail (data with ID), which is a useful behavioral trait beyond the annotations. However, no additional context such as permissions, validation, or side effects is provided, so a middle score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two short sentences: the first front-loads the action, and the second states the return value. Every word earns its place, with no redundant information. This is an appropriate size for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The full schema and annotations cover required parameters and safety profile, and the output schema (present) handles return structure. However, the description does not mention non-idempotency explicitly (though annotated) or any prerequisites like linking to a company. For a create operation, slightly more context about duplicate creation or validation would improve completeness, but it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 9 parameters, so the baseline is 3. The description itself adds no parameter-related meaning, such as relationships between fields or optionality context, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Crée un(e) nouvel(le) contact') and the resource ('BoondManager'), distinguishing it from sibling tools like boond_contacts_get, boond_contacts_search, and boond_contacts_update. The verb 'create' makes the operation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as boond_contacts_update or boond_contacts_search. It only states the action, leaving usage context to be implied from the tool name, which is insufficient for an agent deciding between create and other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe read nature is known. The description adds the return format ('Données JSON complètes') and optional tab behavior, but does not disclose any deeper behavioral traits like error handling, permissions, or the effect of invalid tab values. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action, followed by a clean Args/Returns structure. It is not overly long, though the Args section repeats some information already present in the schema, which is a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get operation (2 params, no output schema, annotations covering safety), the description is sufficient: it states what it retrieves, by ID, optional tab, and the return type. It does not list all possible tab values (also in the schema) or describe edge cases, but overall it is adequate for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'id' and 'tab' already have descriptive text in the schema. The description simply repeats the same meaning without adding extra semantic detail (e.g., value formats, allowed values, or relationships), so it relies on the schema rather than adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère') with a clear resource ('contact par son ID') and states the action: retrieving detailed information. It is clear, but it does not explicitly distinguish this tool from sibling tools like boond_contacts_information or boond_contacts_search, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use it when you have a contact ID and want detailed data, with an optional tab. However, no explicit alternatives or exclusions are provided (e.g., when to use the search tool instead), so guidance is only implicit rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. It does not disclose required permissions, side effects, or idempotency beyond what the annotations already state. The 'POST /deliveries' mention is an implementation detail rather than a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that gets directly to the point with no filler or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for understanding the tool's core purpose, but it lacks details on expected response format or post-creation behavior. However, the schema thoroughly documents all parameters, making the description sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the description adds no extra meaning. It only mentions the project and resource linkage, which is already stated in the schema as required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Boond delivery via a POST endpoint and specifies it is linked to a project and resource. This distinguishes it from sibling tools like boond_deliveries_search and boond_deliveries_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and description (create operation) but no explicit guidance is given about when to use it versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that the tool returns a list and supports filtering by resource, project, and date range, but does not disclose additional behavioral traits such as pagination defaults, result limits, or handling of unknown fields. This aligns with the annotation profile, so an average score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and begins with a clear single-sentence purpose. The Args list and Returns line are logically structured and easy to scan. It omits the 'fields' parameter but overall remains well-organized and free of unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core search purpose, filters, and return type. Since an output schema exists, the simple Returns line is sufficient. However, the omission of the 'fields' parameter from the Args list is a notable gap, and the description does not mention any search-specific behavior beyond the basic filters. Given the tool's moderate complexity, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully describes each parameter. The description's Args list is redundant and less precise (e.g., 'Filtrer par entité liée' groups resourceId/projectId, and 'Période' omits the exact format). Critically, it omits the 'fields' parameter that appears in the schema, potentially misleading an agent into thinking it doesn't exist. This under-delivers relative to the schema and adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recherche des notes de frais dans BoondManager' (search expense reports in BoondManager) with specific filters. The verb 'Recherche' and the resource 'notes de frais' distinguish it from sibling tools like boond_expenses_get (retrieve a single expense) and boond_expenses_create/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching expense reports with filters, and lists available filter dimensions. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'use boond_expenses_get for a single expense'), so usage guidance is only implied, not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that this is not read-only, not idempotent, and not destructive. The description adds the return value context ('Données du/de la facture créé(e) avec son ID'), which is not covered by annotations, but it does not disclose other behavioral details such as required permissions, potential side effects on linked objects, or validation rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences that front-load the primary action and then provide return information. Every sentence contributes meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 optional parameters and an output schema, the description is minimal but adequate. It does not mention potential dependencies (e.g., whether an orderId is required) or clarify that all fields are optional, leaving those details to the schema. The return sentence is useful but redundant if the output schema is visible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 10 parameters with descriptions (100% coverage), so the baseline is 3. The tool description itself adds no additional parameter semantics, leaving the schema to fully document parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb and resource: 'Crée un(e) nouvel(le) facture dans BoondManager'. This distinguishes it from sibling invoice tools like search, get, update, and delete, and also from provider_invoices_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or contrast with other invoice operations, leaving the agent to infer usage solely from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds useful context about logs being 'audit logs' and 'historique des actions utilisateurs', but discloses no additional behavioral traits like pagination behavior or projection handling, which are left to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the purpose stated first and a return statement second. It is free of fluff and front-loaded, though the return sentence is somewhat redundant with the purpose. Still, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the full parameter schema, and the presence of an output schema, the description is sufficiently complete. It states what the tool searches and that it returns a list of logs, while the schema covers parameter details. However, it lacks any context about how this search relates to other log-related tools, so it's not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all four parameters have clear descriptions). The tool description adds no parameter-specific information, so the baseline of 3 is appropriate since the schema carries the full semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Recherche des logs d'audit dans BoondManager (historique des actions utilisateurs)' – a specific verb (search) and resource (audit logs), with context about what logs contain. This clearly distinguishes it from the sibling tool boond_logs_get, which is presumably for retrieving a single log by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as boond_logs_get or boond_actions_search. The description only states what the tool does, leaving the agent to infer usage context without exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description is consistent. However, it does not disclose additional behavioral traits such as pagination, ordering, or error handling, providing minimal transparency beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with explicit Args and Returns sections. It contains no fluff, though it is minimal and could include slightly more context without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval with one parameter, the description provides the purpose, parameter, and return type. It does not mention edge cases or output details, but the tool's simplicity and existing annotations make it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter with a pattern and description. The description's 'ID du projet' is less detailed than the schema, so it adds no new meaning. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving purchase orders (bons de commande) associated with a specific project. The verb 'Récupère' is specific and the resource is well-defined, distinguishing it from generic order search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: given a project ID, fetch its purchase orders. However, the description does not explicitly mention alternatives like boond_orders_search or provide when-not-to-use guidance, so it relies on the reader to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the sensitive nature of the data (salary, HR info) but does not disclose additional behavioral traits like required permissions or response structure. Given the strong annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose in the first sentence. The Args/Returns structure is clear, though the Returns line ('Données administratives et RH de la ressource') is largely redundant with the opening sentence, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with strong annotations and a complete schema, the description provides sufficient context by listing example fields (salary, daily rate, HR info). Without an output schema, it could be more specific about the full return structure, but given the tool's simplicity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter (id) with a detailed description ('Identifiant unique de l'entité BoondManager (numérique)') and 100% schema coverage. The tool description merely restates 'ID de la ressource' without adding meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves administrative information of a resource, with specific examples (salaire, TJM, coût journalier, informations RH). This distinguishes it from sibling tools like boond_resources_technical_data or boond_resources_information, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for accessing administrative/HR data about a resource, but it does not explicitly state when to use this tool versus related tools such as boond_resources_information or boond_resources_technical_data. No exclusions or alternative recommendations are provided, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context by enumerating the types of data returned (skills, experiences, education, certifications, languages, CV), which clarifies the scope beyond a mere read-only operation. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, front-loaded with the action, and logically structured with Args and Returns. The only minor flaw is that the Returns line ('Données techniques et compétences de la ressource') largely duplicates the opening phrase, but this does not detract significantly from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single parameter and no output schema, the description adequately conveys the returned data categories. It lacks detail on response formatting or handling of missing data, but given the low complexity and rich annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'id' parameter with pattern and description, giving 100% coverage. The description repeats the parameter as 'ID de la ressource' without adding new semantics (e.g., format requirements or examples), so the schema carries the interpretive load, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a resource's technical profile (compétences, expériences, formations, certifications, langues, CV...), using a specific verb and resource. While this distinguishes it from generic resource getters, it does not explicitly contrast with sibling tools like boond_resources_information or boond_resources_administrative, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or differing use cases from other resource-related tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context beyond what annotations and the schema provide, such as return format, permissions, or error behavior. It does not contradict annotations, so a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence communicates the purpose without redundancy. It is front-loaded and every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema) and strong annotations, the description is adequate for a simple get-by-ID operation. It clearly states what is returned (detailed information) without needing to enumerate fields. The absence of an output schema is compensated by the ubiquitous getter pattern among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the 'id' parameter, with a clear description of it as a numeric unique identifier. The description's phrase 'par son ID' merely restates the schema, adding no new semantic meaning. Baseline of 3 applies because the schema handles parameter documentation well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) and clearly identifies the resource as 'compte utilisateur' accessed by ID. This distinguishes it from sibling tools like boond_accounts_search, which implies a search operation rather than a direct fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention boond_accounts_search or other getters, nor any prerequisites or exclusions. The context only implies 'use when you have an ID' without stating it explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent déjà que l'outil est en lecture seule, idempotent et non destructif. La description n'ajoute aucune information comportementale supplémentaire, comme le format de retour, les erreurs possibles ou les autorisations requises. Elle se contente de reformuler l'action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
La description est une phrase unique, directe, sans mots superflus, et place l'information essentielle en tête. Elle est parfaitement concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Pour un outil de récupération par ID avec un seul paramètre et d'excellentes annotations, la description est suffisante pour une utilisation de base. Elle aurait pu explicitement mentionner que la réponse contient les détails complets de l'action, mais cela reste implicite et la complexité est faible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma fournit une description complète du paramètre 'id' (type, motif, description). La description de l'outil n'apporte aucune précision supplémentaire sur le paramètre, donc la note de base de 3 s'applique car la couverture du schéma est de 100 %.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La description utilise le verbe 'récupère' avec une ressource précise ('une action') et un critère clair ('par son ID'). Elle distingue bien cet outil des frères comme 'boond_actions_search', 'create', 'update' et 'delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
L'usage est implicite : on comprend qu'il faut avoir l'ID d'une action pour obtenir ses détails. Cependant, aucune alternative n'est mentionnée (par exemple, utiliser 'boond_actions_search' pour trouver l'ID), ni de contexte d'exclusion. Le guidage est minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by noting the optional tab can return specific sub-data and that the response is complete JSON, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, but the 'Args' section duplicates the schema in near-identical wording, wasting space. The 'Returns' line is useful but the overall structure includes redundancy that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with full schema coverage and strong annotations, the description is largely complete. It covers the main behavior, optional tab feature, and return type. It does not detail error conditions or auth, but those are not critical given the tool's simplicity and annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both id and tab. The description repeats these argument definitions almost verbatim, adding no additional meaning or context beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information for a candidate by ID, with an optional tab parameter. It distinguishes from search tools by requiring an ID and covers the specific tab siblings by naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like boond_candidates_search or the specialized tab tools (boond_candidates_information, boond_candidates_technical_data, etc.). The optional tab list implies flexibility, but no explicit direction or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a list, but does not disclose additional behavior such as pagination, sorting, or access requirements. It does not contradict annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a one-sentence purpose, a clear Args block, and a Returns statement. Every sentence is necessary and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description provides enough information: it states the input, the purpose, and the return type. It could mention response field structure or pagination, but given the low complexity and good annotations, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'id' is well described in the schema as 'Identifiant unique de l'entité BoondManager (numérique)'. The description merely repeats 'ID de la société' without adding extra meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Récupère' (retrieves) with a specific resource 'factures fournisseur d'une société' (supplier invoices of a company), making the tool's purpose evident. It is distinct enough from siblings like boond_companies_invoices or boond_provider_invoices_search by virtue of the resource name, though it does not 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a company ID and need its supplier invoices. However, it provides no explicit guidance on when to use this tool over alternatives like boond_provider_invoices_search or boond_companies_invoices, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating that only provided fields are modified and that it returns updated data. It does not contradict the annotations (idempotentHint=true, readOnlyHint=false). However, it does not warn about the destructive replacement of actualExpenses, which is a notable behavior, though that detail is present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with no fluff. It states the action, the partial-update behavior, and the return value in a clear and direct manner, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description is too sparse to be complete for a complex tool. It omits crucial usage context such as the behavior of actualExpenses (replacing all lines) and the need to obtain the full list of lines before adding new ones. The schema contains these details, but the description does not summarize them for the agent, leaving the tool potentially misused.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The tool description does not add any parameter-specific semantics beyond the generic partial-update note, which applies to all parameters equally. It does not explain any parameter interactions or special cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing expense report ('Met à jour un(e) note de frais existant(e)'), with a clear verb and resource. It distinguishes from siblings like create, delete, get, and search by specifying the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It lacks guidance such as 'use create for new reports' or the need to first retrieve the report via get before adding lines because actualExpenses replaces all lines. The partial update note ('Seuls les champs fournis sont modifiés') is a behavior, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 known. The description adds the semantic clarification that positionings are proposed candidates/resources and notes the return type (a list). However, it does not disclose behaviors like pagination, ordering, error handling, or whether only active positionings are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single purpose sentence plus an Args/Returns block. It is front-loaded with the core action and avoids fluff, though the Args section is somewhat redundant with the schema. Still, it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the basic purpose and return type. However, with no output schema, it does not describe the fields of each positioning, any filters, or error behaviors. This is a moderate gap that could affect an agent's ability to handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'id' with type, pattern, and description. The description repeats this parameter in a French phrase without adding new meaning or constraints. With 100% schema coverage, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Récupère' (fetches) and clearly identifies the resource as 'les positionnements (candidats/ressources proposés) sur une opportunité'. This distinguishes it from sibling tools such as boond_opportunities_get, boond_opportunities_projects, or boond_resources_positionings, which are scoped to different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one has an opportunity ID and needs its associated positionings, but it provides no explicit guidance on when not to use it or which alternative tools to consider (e.g., boond_positionings_search for cross-opportunity queries). Given the large sibling set, this leaves room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 adds minimal behavioral context beyond restating the return type ('Liste des projets liés à l'opportunité'). It does not disclose any additional traits such as filtering, pagination, or permission requirements. The value add over annotations is negligible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear purpose statement followed by structured Args and Returns sections. Every sentence earns its place, and the format is easy to parse. It avoids unnecessary elaboration while covering the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and strong read-only annotations, the description is mostly adequate. It explains the input and output but does not describe the output structure (e.g., fields of returned projects). Since there is no output schema, a bit more detail could help, but the core functionality is clear enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'id' generically as 'Identifiant unique de l'entité BoondManager (numérique)'. The tool description specifically clarifies that the id is the 'ID de l'opportunité' (opportunity ID), which is critical for correct usage. Even though schema coverage is 100%, the description adds essential semantic meaning by identifying the entity type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Récupère les projets issus de cette opportunité' (Retrieves the projects from this opportunity). It clearly distinguishes from sibling tools like boond_opportunities_actions or boond_opportunities_positionings by specifying the relationship to projects. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It simply states what it does without mentioning any alternatives or exclusions. There is no 'use this instead of X' or 'when not to use' context, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, idempotentHint=false, and destructiveHint=false, indicating this is a non-read-only, non-idempotent, non-destructive operation. The description adds no further behavioral details, such as side effects, permission requirements, or what happens on success or failure. The only additional information is the purchase relationship requirement, which is more of a constraint than a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise French sentences, each serving a distinct purpose: the first states the action, the second states a key constraint. No redundant language or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and no output schema, the description is too sparse. It does not explain what the tool returns, how parameters interrelate, or typical usage patterns. The single prerequisite about the purchase relationship is useful but far from sufficient for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage, so the baseline is 3. The description does not add meaning beyond the schema; the relationship to a purchase is already clearly represented by the 'purchaseId' parameter description. No parameter-specific guidance or grouping is provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'Cree' (creates) and resource 'paiement fournisseur lie a un achat' (supplier payment linked to a purchase). This distinguishes it from sibling tools like boond_payments_get and boond_payments_search, which focus on retrieval or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage precondition: 'L'API Boond /payments requiert une relation purchase' (the Boond /payments API requires a purchase relationship). This tells the agent that a purchase must exist before creating a payment. It does not explicitly mention alternative tools or when to avoid using it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent operation. The description adds the return behavior (data with ID), which is useful, but it does not disclose other behavioral aspects such as permissions, side effects, or failure modes. It provides incremental value beyond annotations without being rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that immediately state the action and the return value. It is front-loaded, contains no filler, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 9 parameters, the schema fully documents each parameter, and the description covers the return value. There is no output schema shown, so the return statement helps. It is sufficient for a straightforward creation operation, though it could mention any prerequisites or validation rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% descriptive coverage for all 9 parameters, including formats and meanings. The description itself adds no parameter-specific information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Crée' (creates) and clearly identifies the resource 'projet' (project) in BoondManager. This distinguishes it from sibling tools like boond_projects_update or boond_projects_delete. The additional return statement clarifies the tool's outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual comparison to other project-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds that the result is a list of actions, but does not disclose pagination, filtering, or error behavior, which is acceptable given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main sentence front-loaded and a Returns line. However, the Args section duplicates schema information, which is slightly redundant but does not make the description bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema), and the description covers the core functionality and return type. Missing details include whether the actions are paginated or sorted, and what constitutes an 'action' beyond the listed examples, but overall it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter with a pattern and description. The description's Args section merely restates the schema without adding semantic detail, so it provides no extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' and clearly identifies the resource scope ('associées à une ressource'), listing action types (appels, emails, RDV, notes). This distinguishes it from generic action tools or other entity-specific action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The usage is implied by the resource-specific retrieval pattern, but the description does not mention when to prefer this over boond_actions_search or other entity action tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context such as response format, error conditions, or authentication requirements, but it does not contradict the annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that fully conveys the tool's purpose without any wasted words. It is appropriately concise for a simple get-by-ID operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only get operation with full schema coverage and comprehensive annotations, this description is sufficient. The term 'détaillées' gives a sense of the return payload, and no output schema exists to require further explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (id) with a clear description. The tool description reiterates 'by its ID' without adding new semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Récupère), resource (webhook), and scope (par son ID). It implies a detail-oriented get operation, but does not explicitly distinguish itself from the sibling search tool beyond the 'détaillées' phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the need for an ID to use this tool, which implies it is used when the ID is already known. However, it does not explicitly mention when to use search instead or any exclusions, leaving the usage guidance implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, confirming a write operation, and the description aligns with this by saying 'Crée'. The description adds the return behavior (data with ID), but provides no additional context on side effects, required permissions, or edge cases. It does not contradict the annotations, but it does not enrich them significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately state the action and the return value. It is front-loaded and contains no redundant information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema, the description is minimally sufficient but lacks contextual guidance such as which fields are required or any business rules around company creation. The input schema covers required fields, but the description does not reinforce or explain them, leaving the agent to rely entirely on schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a basic label (e.g., 'Ville', 'Nom de la société'). The description does not add further meaning to the parameters beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Crée un(e) nouvel(le) société dans BoondManager' (creates a new company in BoondManager). It uses a specific verb ('Crée') and resource ('société'), and explicitly mentions the return of the created entity with its ID, which distinguishes it from sibling tools like search, get, update, or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new company but provides no explicit guidance on when to use this tool versus alternatives (e.g., update for existing companies). No conditions, prerequisites, or exclusions are stated, leaving the agent to infer context from the tool's name and basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the simple retrieval action, such as pagination or empty-list behavior, but it does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a single sentence and a structured Args/Returns breakdown. Every word is useful and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read-only tool, the description is adequate but sparse. It states the input and a generic return type ('Liste des factures'), but lacks detail about the structure of the returned invoices, and there is no output schema to compensate. This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's description includes the format (numeric string). The description's Args line 'ID du contact' adds a small clarification that the ID refers to the contact, but otherwise repeats schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' with the resource 'les factures' scoped to 'un contact', distinguishing it from sibling tools that retrieve other contact-associated entities like opportunities or projects. The title and description are aligned and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a contact ID and need that contact's invoices, but it does not explicitly mention alternatives such as boond_invoices_search or boond_companies_invoices. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent déjà que l'opération est en lecture seule, idempotente et non destructive. La description n'ajoute pas de contexte comportemental supplémentaire comme les erreurs possibles, les exigences d'authentification ou la structure exacte des données retournées. Elle ne contredit pas les annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
La description tient en une seule phrase concise et immédiatement compréhensible. Elle est front-loaded et ne contient aucun mot superflu.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Pour un outil simple de récupération par ID avec des annotations complètes, la description est minimale mais fonctionnelle. Elle ne précise pas la forme de la réponse (puisqu'il n'y a pas de schéma de sortie), ni la signification exacte de 'détaillées', ce qui laisse une certaine ambiguïté.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma couvre déjà 100% des paramètres, avec une description complète du champ 'id' (identifiant unique numérique). La description se contente de répéter 'par son ID' sans ajouter de nouvelles précisions. Le score de base de 3 est donc approprié.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La description indique clairement l'action (récupérer), la ressource (informations détaillées d'une livraison/CRA) et le critère de sélection (par son ID). Elle se distingue des endpoints de recherche ou de création par l'accent mis sur l'unicité de l'ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
L'usage est implicite : on l'utilise quand on connaît un ID pour obtenir les détails complets d'une livraison. Cependant, la description ne mentionne pas d'alternatives ni de prérequis, comme utiliser d'abord une recherche pour obtenir l'ID, ce qui laisse l'agent sans orientation explicite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds little beyond restating the title's 'informations détaillées' and the ID parameter; it does not mention response format, error behavior, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured, front-loaded sentence that immediately states the action and scope. Every word contributes to clarity, with no unnecessary information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get-by-ID tool with one parameter, the description is minimally viable. However, since there is no output schema, the vague 'informations détaillées' does not give an agent expectations about what fields the returned log contains, leaving a notable completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and the id parameter is fully documented with a pattern and a description ('Identifiant unique de l'entité BoondManager (numérique)'). The description's 'par son ID' simply reinforces the schema without adding new semantic detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) with the resource 'log' and explicitly scopes retrieval 'par son ID' (by its ID). This clearly distinguishes it from the sibling boond_logs_search, which searches for logs rather than fetching one by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'par son ID' gives a clear usage context: this tool is for fetching a single log when its ID is already known. However, it does not explicitly name an alternative like boond_logs_search for cases where the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms it creates a new opportunity and returns the created record with ID. While this adds a small behavioral detail, the annotations already convey that this is a write operation (readOnlyHint false). No additional side effects, authorization needs, or limitations are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and ending with the return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with a rich schema and output schema, the description is minimal but sufficient. It identifies the purpose and return value, but lacks contextual guidance about prerequisites or workflow. Given the schema covers parameter semantics, the description meets the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 15 parameters are fully described in the input schema with 100% coverage. The description adds no parameter-specific detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Crée' (create) with the resource 'opportunité' and system 'BoondManager', clearly distinguishing it from sibling tools like boond_opportunities_update or boond_opportunities_delete. The title reinforces this, but the description adds 'nouvelle' and the system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or how it differs from alternatives. The verb 'Crée' implies usage for new opportunities, but there is no direct guidance or exclusions, so it only provides implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Action irréversible' (irreversible action) and describes confirmation behavior when the MCP client supports elicitation, adding context beyond the annotations. The annotations already declare destructiveHint=true and readOnlyHint=false, which the description aligns with.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with two sentences covering purpose, irreversibility, and confirmation behavior. However, the Args block is redundant with the schema, making it slightly less tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description covers the action, the destructive consequence, and the confirmation mechanism. The presence of an output schema means return values need not be described, and the parameter is fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the id parameter with a pattern and description, and schema coverage is 100%. The description's Args section merely restates 'Identifiant de l'entité à supprimer', adding no additional semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Supprime un(e) opportunité de BoondManager' (Delete an opportunity from BoondManager), using a specific verb and resource. This distinguishes it from sibling tools like boond_opportunities_get, create, update, and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It only warns about irreversibility and confirmation behavior, which is behavioral rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the types of data returned (margin, forecast revenue, costs) but does not address pagination, errors, or other behavioral details. With annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Args/Returns sections are somewhat redundant with the schema but are clearly organized and do not contain unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description sufficiently explains the purpose, parameter, and return content (with example fields). It does not mention error cases or prerequisites, but these are not critical for a straightforward fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description ('Identifiant unique de l'entité BoondManager (numérique)') is already informative. The description's Args section merely restates the id parameter with a more generic label, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère') and resource ('la simulation financière d'une opportunité'), listing example fields (marge, CA prévisionnel, coûts). This clearly identifies the tool's purpose and distinguishes it from sibling tools like boond_opportunities_get or boond_opportunities_information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for financial simulation data but does not explicitly compare with alternatives or state when not to use this tool. No exclusion criteria are provided, so the agent must infer usage from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context: the API lacks dedicated filter parameters, so *Id filters are automatically converted to keyword references. This goes beyond the annotations and helps the agent understand the underlying API behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short explanation, an Args list, and a Returns line. It is relatively concise, though the Args section partially duplicates schema descriptions, making it slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with full schema coverage and strong annotations, the description is complete enough to invoke the tool correctly. It covers the core purpose, API-specific filtering nuance, and return type. It does not describe the structure of each positioning result, but that would typically be in an output schema, which is absent here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's parameter descriptions cover 100% of the parameters, including the conversion to keyword references for each ID. The description repeats this at a higher level but does not add new parameter-level semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Recherche des positionnements' with a clarifying parenthetical about placement of candidates/resources on projects/opportunities. It clearly identifies the resource and the search action, but does not explicitly differentiate from sibling tools like boond_candidates_positionings or boond_positionings_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to filter (via keywords and auto-converted *Id parameters), which is useful usage context. However, it does not mention when to use this tool versus alternatives, such as the dedicated positionings endpoints for specific entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds that actions include calls, emails, appointments, and notes, providing useful scoping, but does not mention pagination, ordering, or any other behavioral details beyond what annotations state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The Args/Returns format is clear, though it slightly duplicates the schema, but no extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single parameter and high schema coverage, the description is adequate. It explains the return value at a high level (list of actions) and the types of actions, which is sufficient given the annotations. However, it lacks detail about the structure of each action, but the tool's simplicity mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description and pattern, so the baseline is 3. The description adds minimal value by labeling the parameter as 'ID du projet', but this is largely redundant given the tool's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves actions (calls, emails, appointments, notes) associated with a project, using the specific verb 'Récupère'. This distinguishes it from sibling tools like boond_opportunities_actions or boond_contacts_actions by explicitly scoping to projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need actions for a specific project, but it does not explicitly compare to alternative tools like boond_actions_search or boond_actions_get, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations déclarent readOnlyHint=true, destructiveHint=false et idempotentHint=true, ce qui indique une opération de lecture sécurisée. La description ajoute un contexte sur le contenu des données (temps passé, jours consommés), mais ne fournit pas d'informations supplémentaires sur d'éventuels effets de bord ou exigences d'authentification. Avec des annotations présentes, la description reste minimale mais cohérente.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
La description est très concise : deux phrases fonctionnelles, suivies de la liste des arguments et du retour. Elle est bien structurée, commence par l'action et la ressource, et ne contient aucun contenu superflu. Chaque ligne apporte une information utile.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
L'outil est simple (un seul paramètre) et les annotations couvrent déjà les aspects de sécurité. Cependant, il n'y a pas de schéma de sortie, et la description ne détaille pas la structure exacte des données retournées (champs, types, format). La mention 'temps passé, jours consommés' donne une indication partielle, mais aurait pu être enrichie.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma couvre 100% des paramètres (un seul paramètre 'id' avec description). La description répète simplement ce paramètre dans la section Args, sans ajouter de détails supplémentaires sur le format, la syntaxe ou les valeurs attendues au-delà de ce que le schéma fournit déjà. La couverture élevée justifie le score de base 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La description utilise un verbe d'action spécifique ('Récupère') et cible une ressource précise ('données de productivité d'un projet') avec des exemples concrets (temps passé, jours consommés). Cela permet de distinguer clairement l'outil de ses frères comme boond_projects_get (qui récupère les informations générales du projet) et boond_reporting_projects (qui produit des rapports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description implique clairement une utilisation pour consulter la productivité d'un projet, mais elle ne précise pas explicitement quand utiliser cet outil plutôt qu'un autre (par exemple, boond_projects_get pour les données générales). L'usage est donc sous-entendu par le nom et la description, mais sans exclusions ou alternatives explicites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description aligns by using 'Récupère'. The description adds context about the type of data returned (marge, CA, coûts, rentabilité) but does not disclose further behavioral traits like caching, performance, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose and args/returns structure. The repetition of 'simulation financière du projet' in both the purpose and returns is slightly redundant but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter, the description is adequate. It names the key financial metrics returned, but since there's no output schema, more detail on the return structure would improve completeness. Annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description and pattern for the id parameter. The description's 'Args: id (string): ID du projet' adds minimal extra meaning beyond the schema's 'Identifiant unique de l'entité BoondManager (numérique)'. So baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a project's financial simulation with specific metrics (margin, revenue, costs, profitability). This specific verb-resource combination distinguishes it from siblings like boond_projects_productivity or boond_opportunities_simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a project's financial simulation, but provides no explicit guidance on when to use this over alternatives or any exclusions. There's no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal context ('informations détaillées') but does not disclose return structure or error behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool with rich annotations, the description is minimally viable but lacks explicit return format or entry condition details, especially with no output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, and the description does not add meaning beyond confirming it is the purchase ID. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Récupère), resource (achat), and method (par son ID), clearly distinguishing this get tool from sibling search/create/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'par son ID' (retrieve when you have an ID), but there is no explicit mention of alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it explicitly warns 'Action irréversible' and explains that a confirmation will be requested if the MCP client supports elicitation. This complements the destructiveHint annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The warning and elicitation note are useful, but the Args section is redundant with the schema, adding minor unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, destructive operation), the description covers purpose, irreversibility, and confirmation behavior. The output schema exists and can explain return values. Missing details like error handling or prerequisites are not critical for such a straightforward delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the 'id' parameter ('Identifiant unique de l'entité BoondManager (numérique)'). The description's Args section repeats this information without adding new details, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Supprime un(e) ressource de BoondManager' (deletes a resource from BoondManager). It uses a specific verb and resource, distinguishing it from sibling tools like boond_resources_create or boond_resources_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention situations where deletion might not be appropriate or point to sibling tools. The intended use is implied by the name and description but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond stating it retrieves details; it does not explain response structure or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and concise, with no unnecessary information. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get-by-ID tool with full schema coverage and strong annotations, the description is adequate. However, it could mention what 'informations détaillées' includes or error behavior, so it falls at minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'id' parameter with a description. The description's 'par son ID' simply reiterates the parameter's role without adding extra meaning. Baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' (retrieves) + resource 'fil de discussion' + method 'par son ID', clearly distinguishing from the sibling thread search tool by indicating it fetches a single entity by identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an ID is known, but does not explicitly state when to use this vs the sibling boond_threads_search. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds that the action is irreversible, which is useful context but doesn't go beyond the annotation's destructive indication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple one-parameter destructive tool, the description plus annotations and output schema cover the essential information. The irreversibility note addresses a key risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with description and pattern, so the description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Supprime' (deletes) with the resource 'absence' and system 'BoondManager', clearly distinguishing it from create/update/search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit usage context, exclusions, or alternatives to other absence tools. The 'irréversible' warning implies caution but doesn't guide when to use it instead of update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds that it returns 'informations détaillées' but does not describe error handling, permissions, or the exact structure of the response. Beyond annotations, it provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose without any redundant phrasing. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID retrieval tool with annotations and a fully described parameter, the description conveys the core behavior sufficiently. However, it lacks any indication of what 'détails' includes in the absence of an output schema, which could be slightly more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter 'id' with a description and pattern. The tool description does not add any additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère') and names the resource ('avantage') with a clear scope ('par son ID'). It distinguishes this tool from sibling search tools like boond_advantages_search and resource-specific endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an ID and need a single advantage's details, but it does not explicitly state when to use it versus alternatives like boond_advantages_search. No alternative tools or exclusions are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond saying 'detailed information', such as return format, error behavior, or permissions. It is consistent with annotations but does not go further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It efficiently states the action, resource, and parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter, good annotations, and no output schema, the description is mostly sufficient. It clearly indicates the purpose, but it does not explicitly describe the return shape or mention the search sibling for locating IDs, leaving a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'id' property is already well-described in the schema as a numeric identifier. The description only repeats 'by its ID' without adding extra meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère') and resource ('business unit') with a clear scope ('par son ID'), which clearly distinguishes it from the sibling search tool (boond_business_units_search). It directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for fetching a single business unit given an ID, but it does not explicitly mention when to use it versus the sibling search tool or any exclusions/alternatives. The usage context is clear but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds context by listing the action types (calls, emails, appointments, notes) and the return format, but it does not disclose additional behavioral traits like pagination or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear sentence, followed by an Args section and a Returns line. Every sentence adds value and there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with one parameter and no output schema, the description adequately covers purpose, parameter, and return type. It could mention pagination or filtering, but the tool's simplicity means the current level is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema already fully explaining the 'id' parameter as a numeric BoondManager entity identifier. The description's 'ID de la société' adds little beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Récupère les actions (appels, emails, RDV, notes) associées à une société' with a specific verb (Récupère) and resource (actions for a company), distinguishing it from sibling tools like boond_contacts_actions or boond_opportunities_actions. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving actions linked to a company, but it does not explicitly mention alternatives such as boond_actions_search or provide when-not-to-use guidance. The context is clear but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds that it returns a list of contacts, consistent with the read-only annotation. It does not disclose additional behaviors like pagination or response structure, but given the annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short lines: a one-sentence purpose, an args list, and a returns statement. It conveys all necessary information without waste, front-loading the primary action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read-only tool. The description specifies the input (company ID) and output (contacts list) sufficiently. Without an output schema, the return statement provides basic information. It doesn't address edge cases like empty lists or errors, but the low complexity keeps this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, and the schema already describes it as a numeric BoondManager entity identifier. The description's 'ID de la société' adds a slightly clearer domain context but does not introduce new semantics like format or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states: 'Récupère les contacts associés à une société' – a specific verb (récupère) and resource (contacts of a company). This distinguishes it from sibling tools like boond_companies_get (company details) or boond_contacts_get (single contact), as it focuses specifically on retrieving the contact list for a given company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you have a company ID and need its associated contacts. It lists the required 'id' parameter as 'ID de la société'. However, it does not explicitly discuss alternatives or exclusions, such as using boond_contacts_search for broader contact searches. Thus usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that the return is a list of projects, but it does not disclose pagination, ordering, permissions, or other behavioral nuances. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a front-loaded main sentence and a structured Args/Returns section. Every word earns its place, and there is no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, no output schema, and clear annotations, the description adequately states input and return type. It could be slightly more detailed about the exact structure of the returned list or edge cases, but given the low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, so the baseline is 3. The description clarifies that the ID refers to a company, but this is largely redundant given the tool name. It adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Récupère' and the resource 'les projets associés à une société', which is specific and distinguishes it from sibling tools like boond_contacts_projects or boond_resources_projects by explicitly naming the company context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving projects of a company, but it does not explicitly state when to use it over alternatives, nor does it mention exclusions like contact or resource projects. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clear. The description adds that the tool returns a list of actions and enumerates the action types, which is useful but minimal. It does not disclose any extra behavior such as pagination, ordering, or authorization requirements, though the read-only nature is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose, followed by a simple Args/Return structure. There is no redundant information or filler. Every sentence earns its place, making it easy for an agent to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description adequately states the return value as a 'Liste des actions liées au contact'. It lists action types, which gives a sense of what will be returned. However, it does not detail the structure of individual action objects, which would be helpful given the absence of an output schema, but the high-level description is sufficient for this basic read-only use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter generically as 'Identifiant unique de l'entité BoondManager (numérique)', while the tool description specifies 'ID du contact' (contact ID). This adds crucial semantic meaning, clarifying that the id must refer to a contact entity. Since schema coverage is 100%, the description's clarification elevates it beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' (retrieves) and clearly identifies the resource: 'actions (appels, emails, RDV, notes) associées à un contact'. It distinguishes from sibling tools like boond_actions_search (general search) and boond_contacts_opportunities (opportunities, not actions) by scoping to contact actions and listing action types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is a read-only lookup for a contact's actions, nor does it explicitly contrast with boond_actions_search or other sibling tools. The 'Args' and 'Returns' sections focus on mechanics, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds only that it retrieves 'informations détaillées' by ID, which is a mild behavioral clarification but not deep context like error handling or response shape. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. Every word contributes to stating what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and robust annotations, the description is largely complete. It lacks an explicit statement of what 'detailed information' includes or error behavior, but the low complexity and clear 'by ID' scope make it sufficiently contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter ('Identifiant unique de l'entité BoondManager (numérique)') with 100% coverage. The description's 'par son ID' reinforces that the ID refers to the contract, adding a small semantic linking, but it does not substantially go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Récupère les informations détaillées d'un contrat par son ID.' It specifies a singular contract by ID, distinguishing it from the sibling create tool and other getters. The title reinforces the same meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a contract ID and need its details, but it provides no explicit context about when to prefer this over alternatives or what to do if the ID is unavailable. No sibling search tool for contracts appears in the list, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey that this is a read-only, idempotent, non-destructive operation. The description adds no further behavioral traits such as rate limits, authentication requirements, or specific return characteristics. It is consistent with the annotations but does not enrich beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the core action and resource, and contains no superfluous wording. It is appropriately concise for a simple get-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward single-ID retrieval tool with no output schema, the description provides sufficient context: it names the resource and the input key. While it does not detail the return format or specific fields, the annotations confirm safety, and the simplicity of the tool means this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description for the 'id' parameter (unique numeric identifier). The description's phrase 'par son ID' merely reiterates the schema's meaning without adding extra detail. Since schema coverage is 100%, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Récupère les informations détaillées d'un(e) drapeau par son ID' (retrieves detailed information of a flag by its ID). It specifies the resource (drapeau/flag), the verb (récupère), and the scope (by ID), distinguishing it from the sibling search tool (boond_flags_search) and other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a flag ID and need its details, but it does not explicitly state when to use this tool versus alternatives like boond_flags_search. No exclusions or contextual guidance is provided, so it falls at the 'implied usage' level rather than clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that results are paginated and returns a list with ID, name, and main details. This provides some context beyond annotations, but does not disclose any deeper behavior such as rate limits or default pagination specifics (which are in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence stating purpose, followed by compact Args and Returns sections. It is front-loaded with the core functionality and contains no redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the rich schema (100% parameter coverage) plus the existence of an output schema, the description is nearly complete. It provides a brief return summary and mentions pagination. However, it does not mention the 'fields' projection parameter in the description, which is a minor gap but covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the 4 parameters, each with descriptions. The description's 'Args' section merely copies the schema for keywords, page, and pageSize, but omits the 'fields' parameter. Therefore, it adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching flags by keywords with pagination. It uses a specific verb ('recherche'), a specific resource ('drapeaux'), and the method ('par mots-clés avec pagination'). This distinguishes it from sibling tools like boond_flags_get, which presumably retrieves a single flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need to search flags by keywords. However, it does not explicitly mention alternatives or when not to use it (e.g., for fetching a specific flag, use boond_flags_get). The usage context is clear but lacks explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the return behavior: 'Returns: Données du/de la bon de commande créé(e) avec son ID' (Returns data of the created order with its ID). This goes beyond the annotations, which are all false and provide no specific behavioral hints. However, it does not disclose other traits like idempotency, side effects beyond creation, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and includes a brief return note. Every word serves a purpose, with no filler or repetition of what is already evident from the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11-parameter schema with 100% descriptions and an output schema, the description is adequate. It clearly states the creation action and the return value. It could be more complete if it noted that all parameters are optional, but that information is already conveyed in the schema. The lack of context about prerequisites or related fields is not critical given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides. It mentions the return value but not parameter nuances, so it neither adds nor detracts from the schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crée un(e) nouvel(le) bon de commande' (Creates a new purchase order), providing a specific verb and resource. It clearly distinguishes this tool from sibling search/get/update/delete tools by focusing on the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Crée' (creates) and the context of being a create operation. However, it does not explicitly mention when to use this tool versus alternatives like search or update, nor does it provide exclusions or prerequisites. The guidance is minimal, relying on the obvious purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint: true, but the description adds valuable context: 'Action irréversible' (irreversible action) and a confirmation request if the MCP client supports elicitation. This goes beyond the annotation's basic destructiveness flag. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loaded with the action. The warning about irreversibility and confirmation is placed immediately after the action verb, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and an output schema, the description provides sufficient context: it states the action, warns about irreversibility, and notes the confirmation behavior. The output schema covers return values, so no further explanation is needed. It could mention side effects on related data, but that is not critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'id', including its pattern and description. The tool description adds no additional parameter semantics, so it stays at the baseline of 3 since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Supprime' (delete) and the resource 'positionnement de BoondManager', clearly distinguishing it from sibling tools like boond_positionings_create, boond_positionings_update, and boond_positionings_get. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as indicating that it is for removing an existing positioning that is no longer needed. There is no mention of prerequisites or contexts where deletion should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds context about the optional tab and return type, but does not disclose error handling, authorization, or response structure nuances. This is adequate but not rich beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a minimal Args/Returns section, all front-loaded with the main action. Every sentence is purposeful, and there is no wasted or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with strong annotations, the description covers the core action, optional tab, and return type. It does not elaborate on error behavior or response structure, but given the tool's simplicity and schema coverage, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the Args section in the description largely duplicates the schema. It only adds a project-specific label for id, which is a minor clarification. No additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed project information by ID, which is a specific verb+resource+scope. It distinguishes from sibling tools like search (no ID needed) and other entity-specific get tools. The optional tab mention further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a project ID and want detailed data, but it does not explicitly mention when to choose this over alternatives like boond_projects_search or boond_projects_information. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds 'detailed information' but does not disclose any additional behavioral traits such as not-found behavior or response shape. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the verb and resource. It is efficient and contains no extraneous words, earning its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-ID tool with one parameter, strong annotations, and no output schema, the description is sufficient. It communicates the purpose and input clearly, and the lack of return-value details is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage with a clear description for the 'id' parameter (unique numeric identifier). The description adds no extra semantics beyond restating 'par son ID', which matches the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (récupère) and resource (facture fournisseur) and specifies the retrieval method (par son ID). This distinguishes it from sibling tools like boond_provider_invoices_search and boond_provider_invoices_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching a single supplier invoice by ID, but does not explicitly state when to use this tool over alternatives or mention the search/create siblings. No exclusion criteria are provided, but the ID-based lookup is clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, informing the agent that this is a safe read operation. The description adds that it returns 'Liste des achats correspondants' (list of matching purchases), but provides no additional behavioral context beyond that, such as pagination behavior, defaults, or handling of empty results. The added value over annotations is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a clear structure: purpose statement, Args list, and Returns line. Every sentence contributes meaning, and the key information is front-loaded. There is no fluff or redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only nature (annotations), full schema coverage, and no output schema, the description adequately covers the essential context for a search tool. It states the resource, lists the main filters, and indicates the return type. The only minor gap is not mentioning the 'fields' projection parameter in the description, but since the schema fully explains it, this is a small omission. Overall, it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with individual descriptions, establishing a high baseline. The description groups keywords, companyId, and projectId as 'Filtres' and page/pageSize as 'Pagination', which adds a small level of categorization. However, it omits the 'fields' parameter entirely from the Args list, and the high-level grouping does not significantly deepen understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recherche des achats et sous-traitances dans BoondManager' (search purchases and subcontracting). It specifies a distinct resource and action, distinguishing it from other purchase-related tools like get/create/delete. The mention of filters and pagination reinforces the search intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies search usage through the verb 'Recherche' and the presence of filter parameters, but lacks explicit guidance such as 'use this to search, use get to retrieve a single item' or any exclusion criteria. This is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description adds useful behavioral details: the API requires both startDate and endDate, and without a perimeter filter the report covers the entire authorized perimeter. It also notes that state/type IDs come from boond_application_dictionary. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the purpose and required-date warning, but it contains a redundant 'period' in the key filters list and a somewhat cluttered structure. It could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter tool with no output schema, the description provides a high-level map and key caveats, but the return value is only described as 'Données de reporting,' which is too vague. It does not describe the shape of the response or how to interpret the results, leaving a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds meaningful grouping of key filters (perimeter, period, reportingType, reportingCategory, etc.), clarifies the startDate/endDate relationship, and explains the default perimeter scope, going beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a global synthesis report covering commercial, HR, recruitment, billing, etc. It distinguishes itself from sibling reporting tools by emphasizing 'globale' and the list of categories, though it lacks an explicit verb like 'retrieve' or 'generate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: when to use it (global reporting synthesis) and what the main filters are. It warns that startDate + endDate are required by the API and explains the default perimeter behavior. However, it does not explicitly state when not to use it or name alternative reporting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a semantic clarification (placements sur des projets) and confirms the return type, but does not disclose additional behavioral traits like pagination or ordering. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear intro sentence and a simple Args/Returns structure. Every sentence serves a purpose, and the key verb and scope are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, strong annotations, and no output schema, the description provides essential info: what it fetches and a basic return type. It could mention whether it returns all positionings or any filters, but it is largely complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's description for 'id' is actually richer ('Identifiant unique de l'entité BoondManager (numérique)') than the description's 'ID de la ressource'. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Récupère les positionnements... d'une ressource', using a specific verb and resource scope. It distinguishes itself from siblings like boond_opportunities_positionings or boond_candidates_positionings by explicitly mentioning 'ressource' and clarifying that positionings are 'placements sur des projets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a resource ID and need its positionings, but it does not explicitly state when to use this tool vs alternatives like boond_positionings_get/search. There is no when-not-to-use or alternative comparison, so it stays at an implied-usage level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no additional behavioral context (e.g., permissions, response format, error behavior) beyond what the annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter, read-only get tool, the description is adequate. It could be more explicit about what 'detailed information' includes, but the lack of an output schema and the simplicity of the operation make it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'id' with a pattern and description. The description merely restates 'par son ID' without adding extra meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'récupère' (retrieves) with the resource 'validation' and specifies it does so 'par son ID' (by its ID). This clearly distinguishes it from sibling tools like boond_validations_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you have a specific validation ID and need its details. It does not explicitly exclude alternatives or mention when not to use it, but the context is clear for a get-by-ID operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the required month parameters and keyword prefixes, but these are already present in the schema, so minimal new behavioral insight is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a warning and a bullet list of arguments. While the Args section is largely redundant with the schema, it is concise and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify return values more, but it only says 'Liste des validations correspondantes.' It does not explain pagination or the fields projection parameter, though the schema covers these in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions and enums for all parameters. The description repeats the month formats and enum values but does not add new semantic meaning beyond the schema, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for pending validations in BoondManager, listing document types (absences, expense reports, timesheets). The verb 'Rechercher' and the specific resource 'validations' distinguish it from sibling tools like boond_validations_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by noting that startMonth and endMonth are required and lists optional filters like documentTypes and validationStates. However, it does not explicitly mention when to prefer this tool over alternatives such as boond_validations_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns a list of matching actions, which is useful but does not disclose pagination behavior, field projection effects, or what constitutes the standard summary. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence summary, a bulleted Args list, and a Returns line. It is front-loaded and every sentence adds value without unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description provides a basic list of arguments and a vague return description ('Liste des actions correspondantes'). It omits the 'fields' projection parameter from its Args list and does not explain default behavior (e.g., if no filters, all actions are returned). This leaves gaps for an agent to fully understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description repeats the purpose of keywords and entity IDs, but omits the 'fields' parameter entirely and adds no extra syntax or format details. This aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches actions (calls, emails, appointments, notes) in BoondManager with optional filters. This differentiates it from sibling tools like boond_actions_get (retrieve a single action) and boond_actions_create/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via optional filters by candidate, resource, contact, or company, indicating when this tool is appropriate. However, it does not explicitly state when to prefer this over alternatives or provide exclusions, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is disclosed. The description adds context about the data payload scope (technical skills, resume) and does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single clear sentence and compact Args/Returns format. Every part is informative and directly useful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema. The description lists the major content categories returned but does not describe response structure or potential error conditions. For a simple read operation with strong annotations, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the 'id' parameter with type string and pattern for numeric digits, offering 100% coverage. The description merely restates 'ID du candidat', adding no new semantic information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) and identifies the resource as the technical profile of a candidate, enumerating content areas (skills, experiences, training, certifications, languages, CV). This clearly differentiates it from sibling tools like boond_candidates_information or boond_candidates_administrative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a candidate's technical profile is needed but does not explicitly state alternatives or when-not-to-use. It does not mention that boond_candidates_get might return basic info or that boond_candidates_information covers other aspects, leaving the choice to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds that it returns complete JSON data and supports optional tabs, which is some behavioral context, but it doesn't go beyond that or contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main action and resource. However, the Args section duplicates the schema, adding some redundancy, so it's not perfectly optimized, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with strong annotations, the description covers purpose, parameters, and return type. It lacks details on error handling or the relationship to specialized endpoints like boond_companies_information, but is adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both id and tab described. The description repeats these args without adding new semantics, so it provides no value beyond what the schema already documents. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information for a company by ID, with optional tabs (information, technical, financial, actions, contracts, documents). This specific verb+resource combination distinguishes it from search and other entity-specific get tools, even though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use this when you have a company ID and want detailed information, optionally specifying a tab. It doesn't mention when not to use it or name alternative tools, but the prerequisite of having an ID is implied and the optional tab guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotent=false. The description adds valuable behavior: 'Action irréversible' explicitly states permanence, and it documents that a confirmation prompt may appear if the MCP client supports elicitation. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a clear first sentence states the action, followed by a warning and a confirmation note. The Args block is somewhat redundant given the schema, but the overall length is appropriate and each sentence carries meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description plus annotations are complete: purpose, irreversibility, and confirmation behavior are covered. The output schema exists, so return details are not required in the description. Minor additions like error handling or permissions are not necessary for this minimal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the sole 'id' parameter with type, pattern, and description. The description's Args section essentially repeats the schema ('Identifiant de l'entité à supprimer') without adding new semantic details beyond clarifying that the id targets the entity to be deleted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the explicit verb 'Supprime' and identifies the resource as 'un(e) contact de BoondManager', making the action clear and specific. This differentiates it from sibling tools such as boond_contacts_search, get, create, and update, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting a contact but does not provide explicit guidance on when to use it versus alternatives, such as update for corrections or delete tools for other entity types. It adds context about irreversibility but lacks any 'when not to use' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds that it returns a list of matching deliveries with pagination, which is useful but not deeply revealing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, a categorized Args list, and a Returns line. It is front-loaded with the main purpose, though the Args list is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 100% schema coverage and no output schema, the description provides a clear purpose, parameter overview, and return type. It lacks explicit details about date semantics or result field structure, but is otherwise sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's Args section largely duplicates the schema, merely grouping parameters into keywords, entity filters, period, and pagination. It adds marginal context like 'entite liee' but no substantial new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Recherche des livraisons (comptes rendus d'activite) dans BoondManager' with filters by project, company, and period. The specific verb 'Recherche' and resource 'livraisons' distinguish it from sibling tools like boond_deliveries_get (single retrieval) and boond_deliveries_create (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: searching for deliveries with optional filters. It implies broad lookup use but does not explicitly mention alternatives or when not to use it, such as using boond_deliveries_get for a specific record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnly, idempotent, and non-destructive behavior, the description adds value by clarifying that 'category' must be a singular string (not an array) and that the return is a list. This goes beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a warning, args list, and returns. It front-loads the purpose and avoids unnecessary prose, though the args list somewhat duplicates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete schema and annotations, the description sufficiently covers the essential behavior for a read-only search tool: it specifies the return type and the required category parameter. It does not explain pagination or projection, but those are already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces the required category enum and adds the singular-array nuance, but does not add meaningful extra semantics for state, parentType, page, pageSize, or fields, which are all well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Recherche des notifications dans BoondManager' (search notifications in BoondManager), giving a specific verb and resource. It does not explicitly distinguish from sibling boond_notifications_get, though the 'search/get' distinction is implicit in the names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for searching notifications and emphasizes that category is required, which is a key usage constraint. However, it does not mention alternatives or explicitly state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it warns that the action is irreversible and notes that a confirmation may be requested if the MCP client supports elicitation. This complements the destructiveHint annotation by clarifying the permanence and interaction flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action and the critical warning. The Args block is somewhat redundant given the detailed schema, but it doesn't significantly bloat the text. Overall, it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete tool, the description covers the key aspects: the action, irreversibility, confirmation behavior, and the parameter. Since an output schema exists, return values are not required in the description. It lacks mention of permission requirements or error cases, but these are not critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the 'id' parameter is fully documented in the schema. The description's Args section repeats the parameter name and a brief label but adds no new semantic information beyond what the schema already provides (e.g., numeric pattern).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Supprime un(e) produit de BoondManager' (deletes a product from BoondManager). This specifies the verb (delete), the resource (product), and the system, effectively distinguishing it from sibling delete tools targeting other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—use when you need to delete a product—but provides no explicit guidance on when to use this tool versus alternatives, such as boond_products_update or boond_products_get. It also doesn't mention prerequisites like the product needing to exist or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the optional tab behavior and the return type (complete JSON data), but does not disclose error handling, pagination, or what each tab contains. With annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose in the first sentence. The Args and Returns sections are clear but repeat the schema information almost verbatim, making them slightly redundant. Still, it is concise and structurally sound, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with strong annotations and full schema coverage, the description is sufficiently complete: it covers the ID requirement, optional tab, and return type. It does not explain the meaning of each tab, but that is minor given the available context and the tool's simplicity. No output schema exists, but the return description compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (id and tab) with 100% coverage. The description repeats these details but adds no new meaning beyond the schema, as the list of tabs is identical in both. The baseline of 3 applies because the schema does the heavy lifting and the description offers no further clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Récupère' (fetches) and the resource 'produit' (product) with the method 'par son ID' (by its ID). It also distinguishes from sibling tools like boond_products_search, boond_products_create, and other entity getters, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it: to fetch detailed product information by ID, with an optional tab parameter. It implicitly differentiates from search (which finds products) and create/update/delete, but does not explicitly rule out alternatives or state excluded cases. No explicit when-not or alternative mentions, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to repeat safety. It adds useful behavioral context: without perimeter filters the report covers the entire authorized scope, and states/types must come from boond_application_dictionary. This goes beyond annotations, though it does not mention caching or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with purpose, and uses labeled lines ('Filtres clés', 'Returns'). It is easy to scan. The only flaw is the phantom 'period' reference, which slightly detracts from precision, but overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 22 parameters and no output schema, the description covers the main behavioral rules (default perimeter, dictionary IDs) but offers only a generic 'Données de reporting' for return values. It does not explain the structure of the response or how filters combine by default (OR vs AND), which is left to the schema. Given the richness of the schema, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, giving a baseline of 3. The description groups filters (perimeter, period, projectTypes, etc.) which adds some structure, but it incorrectly mentions a 'period' parameter that does not exist in the schema (only startDate/endDate and periodDynamic are present). This misleading reference outweighs the organizational benefit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reporting des projets (CA, marge, rentabilité...)' which is a specific verb+resource pairing that clearly distinguishes this tool from sibling reporting tools (boond_reporting_companies, boond_reporting_resources, boond_reporting_synthesis). It also outlines key filters, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: project reporting with filters for perimeter, period, project types/states, resources, etc. It also explicitly notes the default scope behavior ('Sans filtre de périmètre, le reporting porte sur tout le périmètre autorisé'). However, it does not explicitly name alternative tools for when not to use this one, e.g., boond_reporting_companies for company-level reporting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that it returns a list of expense reports, which is useful but does not go into additional behavioral traits such as data filtering or authorization requirements. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clean structure: one sentence for purpose, an Args section, and a Returns section. Every line serves a purpose, and there is no wasted text. It is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only) and the presence of safety annotations, the description is largely adequate. However, it does not describe the structure or fields of the returned expense reports, and there is no output schema to compensate. It also does not mention whether results are paginated or limited, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'id' as a unique numeric identifier without specifying the entity type. The description's Args section explicitly states 'ID de la ressource', clarifying that the id refers to a resource. This adds meaning beyond the schema's generic 'entité BoondManager' wording, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves expense reports for a resource, using the specific verb 'Récupère' and specifying the resource. This distinguishes it from sibling tools like time reports or absence reports, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a resource's expense reports, given the resource ID. However, it does not explicitly mention alternatives like boond_expenses_search or boond_expenses_get, nor does it state when not to use this tool. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no new behavioral context beyond what annotations and the schema provide, which is acceptable for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded French sentence that precisely states the action, resource, and lookup method. Every word is functional, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only, idempotent getter with strong annotations, the description is sufficient. The word 'détaillées' reasonably implies a full entity object response, and the lack of output schema does not create ambiguity for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'id' parameter, so the schema carries the semantic weight. The description's 'par son ID' merely restates the schema without adding extra meaning or constraining behavior further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' and resource 'todolist', and explicitly states the retrieval method 'par son ID', clearly distinguishing this get-by-ID tool from the sibling search tool. The scope is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific todolist ID is known, but does not explicitly mention alternatives like boond_todolists_search or provide when-not-to-use guidance. The ID parameter and 'par son ID' hint at the use case, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: the tool returns a text runbook that the model must subsequently execute via referenced Boond tools, and the perimeter can be auto-resolved by agency/manager name. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused, front-loaded sentences: core function, client context, and output behavior. Each sentence earns its place. The second sentence about the MCP prompt equivalence is slightly niche but relevant for adoption decisions, so the structure remains efficient without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value ('runbook texte') and its content (top/rare/missing skills). It covers the perimeter variants, the execution pattern, and the client context. Minor gaps: no detail on runbook format, which Boond tools are referenced, or edge cases like empty perimeters, but this is acceptable for a composite workflow tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with rich, self-sufficient parameter descriptions (defaults, alternatives, auto-resolution via `boond_agencies_search`/`boond_resources_search`, and default scope behavior). The description's mention of 'équipe, agence' and 'top compétences' subtly reinforces the parameters' roles, but it adds no essential information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Produit une cartographie') and a clear resource (compétences techniques d'un périmètre), and enumerates the concrete outputs (top compétences, compétences rares/risque bus-factor, compétences manquantes). It distinguishes itself from sibling workflows like `boond_workflow_recherche_profil_competences` by framing this as a perimeter-level mapping rather than a profile search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual usage signals: it is the tool equivalent of the MCP prompt `cartographie_competences`, useful for clients (e.g., claude.ai) that don't handle MCP prompts well. It also explains that the returned runbook must be executed by the model. However, it does not explicitly state when to prefer this over sibling workflow tools, nor does it mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful behavioral detail: 'resourceId est converti en COMP<id>', and specifies the period format YYYY-MM, but does not describe other behaviors like pagination defaults or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, well-structured with 'Args:' and 'Returns:' sections, and every line provides value without repeating the schema verbatim. It is front-loaded with the core purpose and then lists parameter details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 7 optional parameters and no required ones. The description covers the overall purpose, mentions the key filter dimensions, and summarizes the return value. With strong annotations and complete schema descriptions, the definition is adequate, though a bit more detail on the return format could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving a baseline of 3. The description adds meaning beyond the schema with the conversion rule 'resourceId est converti en COMP<id>', which is not present in the parameter descriptions. This is a meaningful addition that helps the agent understand how to use the resourceId parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Recherche des demandes d'absence dans BoondManager' with a specific verb ('Recherche') and a clear resource ('demandes d'absence'). It distinguishes from sibling tools like boond_absences_get or boond_absences_create by signaling a search operation with filter criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the verb 'Recherche' and the list of filter parameters, but there is no explicit guidance on when to use this tool versus alternatives such as boond_absences_get or boond_planning_absences_search. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds that the action is irreversible and that a confirmation may be requested if the MCP client supports elicitation. These are important behavioral details that help the agent manage side effects and user interaction. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the action and resource, and immediately follows with the critical warning about irreversibility and confirmation. Every sentence earns its place without repeating schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description covers the essential behavioral traits (irreversibility, possible confirmation) and the schema covers the parameter. The presence of an output schema handles return values. Minor omission of related side effects or prerequisites, but sufficient for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter 'id' with a numeric pattern and a clear description. The tool description does not add any additional semantic value for the parameter. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an action from BoondManager ('Supprime une action de BoondManager'), using a specific verb and resource. It distinguishes this from other delete tools for different entities (e.g., boond_candidates_delete) by specifying 'action'. The title reinforces but the description adds the BoondManager context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided, but the delete semantics imply usage when an action needs to be removed. The description does not contrast with boond_actions_update or boond_actions_get, leaving selection to the agent's reasoning based on the clear purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is known. The description adds the types of actions included (appels, emails, RDV, notes) but does not disclose other behavior such as pagination, ordering, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear main sentence followed by Args and Returns sections. Every sentence is useful and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (single parameter, read-only, no output schema). The description states what it returns (list of actions) and even lists example types, which is adequate for a basic retrieval operation. Minor missing details like sorting or pagination are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a parameter description. The description restates that 'id' is the candidate ID, slightly clarifying the generic schema phrase 'entité BoondManager', but adds minimal extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) with the resource 'actions associées à un candidat' and lists examples (appels, emails, RDV, notes). This clearly distinguishes it from sibling tools that operate on other entities or actions in general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies this tool is for fetching actions tied to a specific candidate, which provides context on when to use it. However, it does not explicitly mention alternatives or exclusion criteria, e.g., when to use boond_actions_search instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the return is a list of opportunities, but it does not disclose error behavior or any additional side effects. It is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the action stated in the first sentence, followed by clearly formatted Args and Returns sections. Every element earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and annotations cover safety. The description gives the return type ('Liste des opportunités') but lacks detail about the structure of each opportunity or error handling, which would be helpful given there is no output schema. Still, it is nearly complete for a straightforward read resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides full coverage with a description of 'id' as the unique numeric identifier of the BoondManager entity. The description merely repeats 'ID du contact' without adding detail about validation or format beyond the schema's pattern. Hence baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Récupère les opportunités commerciales associées à un contact' (retrieves commercial opportunities associated with a contact), using a specific verb and resource. It distinguishes itself from sibling contact sub-resources (projects, orders, invoices) and company opportunities by focusing on contact associations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need a contact's opportunities, which is clear context. It does not explicitly mention alternatives like boond_opportunities_search or boond_companies_opportunities, nor does it provide exclusion criteria, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that it returns a list of orders, which is basic but does not disclose pagination, ordering, or potential errors. This is adequate but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. It states the purpose in one sentence, then lists the parameter and return type in a structured format. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, no output schema, and strong safety annotations, the description is largely complete. It clearly specifies the input and the high-level return (a list of orders), though it omits any detail about the structure of the returned list or edge cases. Given the low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single 'id' parameter is described with its numeric pattern and purpose. The description's inclusion of 'id (string): ID du contact' adds no new meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Récupère les bons de commande associés à un contact' (Retrieves the purchase orders associated with a contact). It uses a specific verb (récupère) and resource (bons de commande / orders) and distinguishes itself from sibling contact-related tools like actions, opportunities, projects, and invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need to retrieve purchase orders for a specific contact. No explicit exclusions or alternatives are mentioned, but the narrow scope and naming pattern (including sibling tools) make the use case obvious without further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'Récupère' and 'Returns: Liste des projets' are consistent with the annotations (readOnlyHint=true, destructiveHint=false). It adds minimal behavioral context beyond the annotations, such as the input-output relationship, but no mention of pagination, filtering, or permissions. Annotations already cover safety, so this is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with an Args and Returns section. It is front-loaded with the main purpose in the first sentence, and every line adds necessary information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is adequately complete: it states the input and the returned entity type. It could further specify output structure or edge cases (e.g., empty list), but given the tool's simplicity and the presence of annotations, it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a generic description for 'id' as 'Identifiant unique de l'entité BoondManager (numérique)'. The description adds specific meaning by labeling it 'ID du contact', clarifying that the id refers to the contact entity. This adds value beyond the schema, though the schema already covers 100% of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Récupère les projets associés à un contact' (retrieves the projects associated with a contact), which combines a specific verb and resource with the scope of a contact. This distinguishes it from sibling tools like boond_contacts_opportunities, boond_contacts_orders, and boond_projects_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a contact's projects) but provides no explicit exclusions or alternative recommendations. It does not mention when not to use it or name any sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark destructiveHint=true and readOnlyHint=false. The description adds that the action is irreversible and that confirmation will be requested if the MCP client supports elicitation, which is valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, followed by a necessary warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema, the description provides the action, irreversibility, and confirmation behavior. It is sufficient for an agent to invoke it safely, although it doesn't mention potential failure modes or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'id' parameter with a pattern and description (100% coverage). The tool description adds no additional parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Supprime un document de BoondManager' (deletes a document from BoondManager), which is a specific verb+resource. It distinguishes from sibling tools like boond_documents_get and boond_documents_create by indicating deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting a document, and the warning about irreversibility gives a cautionary context. However, it doesn't explicitly state when to use vs alternatives or provide any exclusions. Since the tool is a standard delete operation, this is acceptable but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it warns 'Action irréversible' and states that a confirmation is requested if the MCP client supports elicitation. These are useful details not present in the destructiveHint annotation, though the annotation already signals destructive intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and including only essential warnings. Every word serves a purpose with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers the action, irreversibility, and confirmation handling. Since an output schema exists, return values need not be described. Minor omissions like error cases or prerequisites prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'id' parameter with a pattern and a description. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Supprime une note de frais de BoondManager', clearly stating the action (delete) and the resource (expense note) with a specific system (BoondManager). This distinguishes it from sibling tools like boond_expenses_get or boond_expenses_update, and matches the title exactly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to delete an expense note, but it does not explicitly mention when not to use it or compare it to alternatives (e.g., update instead of delete). The irreversibility warning gives some caution but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read. The description adds the word 'detailed' but does not disclose any additional behavioral traits such as response shape or potential errors. It doesn't contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function. No filler or repeated information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a get-by-ID operation, the one-sentence description is adequate. It benefits from strong annotations and full parameter documentation. However, it doesn't describe what 'detailed information' includes or the return format, which would be more critical if there were no output schema; still, it's enough for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (id) with a clear description and pattern. The description does not add any additional parameter-level semantics beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) with a clear resource ('note de frais') and specifies the identifier ('par son ID'). This clearly distinguishes it from sibling tools like boond_expenses_search, which target lists rather than a single entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool fetches a single expense report by ID. It doesn't explicitly mention alternatives like boond_expenses_search, but the 'by ID' qualifier clearly differentiates this from search operations. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds only that it retrieves 'detailed information', which is a minor addition beyond the annotations. No additional behavioral context (e.g., error behavior, pagination, or response format) is provided, but none is strictly necessary given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in French, front-loaded with the action and resource. There is no redundant information or filler. It earns its place by succinctly communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, full schema, clear annotations), the description is nearly complete. It clarifies the input (by ID) and the output type (detailed information). However, since there is no output schema, the description could be slightly richer about what 'detailed information' includes, but this is a minor gap for a straightforward get-by-ID operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameter, describing 'id' as the unique numeric identifier of the BoondManager entity. The tool description does not add any parameter-specific semantics beyond what the schema already provides. According to the rubric, high schema coverage means a baseline of 3, and the description does not compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Récupère les informations détaillées d'un(e) facture par son ID' (retrieves detailed invoice information by ID). It specifies a concrete verb ('récupère'), a clear resource ('facture'), and the lookup mechanism ('par son ID'). This distinguishes it from sibling tools like boond_invoices_search (which searches) and boond_invoices_create/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys usage: when you have an invoice ID and need detailed information, use this tool. It clearly indicates the required input ('par son ID') and the purpose. However, it does not explicitly mention when not to use it or name alternatives such as boond_invoices_search, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that the operation retrieves 'informations détaillées', which is minor and does not disclose additional behavioral traits such as return format, pagination, or rate limits. This is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately states the action and the parameter requirement. It is front-loaded with the main verb and resource, contains no filler, and is appropriately sized for a simple get-by-id operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low in complexity (one required parameter, no output schema, no nested objects) and the annotations provide safety context. The description sufficiently covers what the tool does and hints at the return being 'detailed information'. While no output schema exists, the simplicity of a get-by-id typically makes the response shape predictable enough for the AI agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the 'id' parameter, including its type and a description ('Identifiant unique de l'entité BoondManager (numérique)'). The description only reiterates that the lookup is 'par son ID', adding no new meaning beyond what the schema already documents. Thus the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère') and resource ('notification'), and specifies the retrieval method ('par son ID'). It clearly distinguishes from sibling tools like boond_notifications_search, which lists notifications rather than fetching a single one by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the context: use this when you have a notification ID and need its details. It does not explicitly mention alternatives or when not to use it, but the 'by its ID' phrasing implies that a prior search or listing is needed to obtain the ID, giving clear usage context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds key behavioral detail: partial update ('Seuls les champs fournis sont modifiés') and indicates the return value ('Données mises à jour'). These are not captured in the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and provide useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, then a clear partial-update note and returns line. Every sentence is informative with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters, the description is minimal but sufficient because the schema carries detailed parameter semantics and the annotations cover safety. The partial-update behavior and return value are the missing contextual pieces, and they are provided. It could mention typical usage patterns but is not incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the parameters with detailed descriptions, so baseline is 3. The description adds no parameter-specific meaning beyond the general partial-update note, which applies to all parameters equally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Met à jour un(e) opportunité existant(e) dans BoondManager' with a specific verb (update) and resource (existing opportunity), clearly distinguishing it from create, delete, get, and search sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing opportunity ('existant(e)') but does not explicitly state when to use it vs alternatives like create or delete, nor any exclusions or prerequisites. Usage context is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the adjective 'détaillées' (detailed) but provides no additional behavioral context such as error handling or response format. This is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence in French that front-loads the action and resource. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with a single parameter and rich safety annotations, the description is adequate. It doesn't specify the exact return fields, but 'detailed information' implies a full order object, and no output schema exists to explain further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'id' parameter with pattern and description, achieving 100% coverage. The description merely reiterates the ID-based lookup without adding format or semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'récupère' (retrieves) and identifies the resource as 'bon de commande' (purchase order), with 'par son ID' clearly distinguishing this from search or listing tools. It directly reflects the title but adds the ID-based retrieval scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific order ID and need its details, but it does not explicitly contrast with boond_orders_search or mention when not to use it. The context is clear but no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a little context by stating it gets 'detailed information' but does not disclose any unexpected behavior, auth requirements, or return format. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully documented parameter and clear annotations. The absence of an output schema is partially mitigated by the explicit 'detailed information' phrase, though the agent might not know the exact structure of the returned payment. Overall, it is sufficiently complete for a straightforward get-by-ID operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since the 'id' parameter is fully described as 'Identifiant unique de l'entité BoondManager (numérique)'. The tool description merely repeats that the lookup is by ID, adding no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed payment information by ID, using a specific verb ('Recupere') and resource ('paiement / reglement'). It is distinct from the sibling boond_payments_search, as it is a by-ID lookup rather than a search, and the title 'Details d'un paiement' reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a specific payment ID and need its details, which is clear context. It does not explicitly name alternatives or exclusions, such as when to use boond_payments_search instead, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by noting that invoiceId and companyId are kept for compatibility, that keywords support Boond-specific filter codes, and that the return is a list of matching payments. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args section and a Returns line, making it easy to scan. It is reasonably concise, though the parameter list partially duplicates schema information and omits some parameters, causing minor inefficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 optional parameters and no output schema, the description provides a high-level overview but misses key context. It does not mention the 'fields' parameter for projecting attributes, nor important filters like projectId, purchaseId, and resourceId. It also doesn't clarify that all filters are combinable. The schema compensates, but the description alone is incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions (100% coverage). The description adds meaningful semantics for keywords by explaining the special ACH/CSOC/PRJ filtering syntax, and for invoiceId/companyId by flagging them as compatibility parameters. However, it omits several schema parameters (projectId, purchaseId, resourceId, fields), even though the schema covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Recherche des paiements / reglements dans BoondManager' (search payments/settlements), which is a specific verb+resource. The name and title reinforce this as the search tool, distinguishing it from boond_payments_get and boond_payments_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context, such as the special keyword codes (ACH<id>, CSOC<id>, PRJ<id>) for filtering by purchase, company, or project. However, it does not explicitly state when to prefer this tool over alternatives like boond_payments_get or mention any exclusions, leaving the selection guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that it returns 'informations détaillées', but does not elaborate on response structure or any side effects. It is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the action, resource, and method. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with strong annotations and a single fully documented parameter, the description is adequate. It does not explicitly state the return format, but the behavior is self-evident and the annotations cover the operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter with type, pattern, and description (100% coverage). The description only repeats 'by its ID', adding no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'récupère' and specifies the resource 'pôle' and the method 'par son ID', clearly distinguishing it from search or list tools like boond_poles_search. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies that this tool is used when a specific pole ID is known ('par son ID'), providing clear context. However, it does not explicitly mention alternatives like boond_poles_search for when the ID is not known, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the schema (e.g., what 'détails' includes, pagination, or error cases). With annotations present, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, front-loaded sentence with no redundancy. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter, the description is adequate. However, there is no output schema and the description doesn't specify what 'informations détaillées' includes, leaving some ambiguity about return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the single 'id' parameter is fully described with pattern and description. The description's 'par son ID' adds no new meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Récupère'), identifies the resource ('positionnement'), and scopes it by ID, clearly distinguishing it from search, create, update, and delete sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and description clearly imply this is the get-by-ID tool for positionings; however, it doesn't explicitly state when to use it instead of boond_positionings_search or that search should be used to find IDs. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates a product and returns the created product's data with ID. It aligns with annotations (readOnlyHint=false, destructiveHint=false) and adds return value context, but does not go deeper into permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, one for purpose and one for return value. No redundant information, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description covers the purpose and return value. The presence of an output schema and complete parameter descriptions makes this sufficient, though it could mention typical validation or duplicate handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all six parameters with 100% coverage, so the description doesn't need to add parameter details. It adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (product) within BoondManager, using a specific verb and noun. It distinguishes from sibling product tools (search/get/update/delete) by the create verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool for creating a product. However, it does not explicitly mention when not to use it or reference alternatives like update or delete, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, but the description adds valuable context: the action is explicitly irreversible ('Action irréversible') and mentions that confirmation is requested before deletion when the MCP client supports elicitation. This goes beyond the structured metadata and clarifies real-world side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the purpose, the second delivers the critical warning and confirmation behavior. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with annotations and an output schema, the description provides sufficient context. It could mention what happens to related data or required permissions, but the irreversibility warning covers the main risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description for 'id' (unique numeric identifier). The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Supprime') and the resource ('un achat de BoondManager'), which is a specific verb+resource pair. The title further clarifies scope with 'achat/sous-traitance'. This distinguishes it from other purchase tools (e.g., get/search/create) and other entity delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives or prerequisites beyond the id. The usage is only implied by the verb 'Supprime'; there are no stated exclusions, required prior steps, or references to sibling search/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral details: that startDate/endDate are required by the API, that state/type filters use integer IDs from boond_application_dictionary, and that the default scope is all authorized perimeter when no perimeter filter is applied. These are not redundant with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose and critical requirement (startDate/endDate). The 'Returns: Données de reporting' line is somewhat redundant but not harmful. Minor issues like referencing 'period' not in the schema prevent a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 23-parameter tool, the description provides a useful high-level overview but omits details about the return structure (no output schema exists) and pagination/caching options. It is adequate for selection but leaves the agent to rely on the schema for operational specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter description coverage, so the baseline is 3. The description only groups parameters at a high level (périmètre, période, etc.) without adding new syntax or semantics. It even mentions a 'period' parameter that is not actually present in the schema, which could cause minor confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Reporting des plans de production (disponibilités, positionnements...)' with a specific resource and subject matter, distinguishing it from sibling reporting tools like boond_reporting_resources or boond_reporting_synthesis. The verb is implied but obvious in context (provides reporting), and the scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it requires startDate/endDate, lists key filter groups, and explains the default behavior when no perimeter filter is set ('Sans filtre de périmètre, le reporting porte sur tout le périmètre autorisé'). However, it does not explicitly compare with sibling reporting tools or state when not to use it, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond annotations by disclosing the optional tab behavior and the return format ('Données JSON complètes de l'entité'), though it does not address error cases or authorization. With annotations carrying the safety burden, the added context warrants a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written: one main sentence, a compact Args block, and a Returns line. It is front-loaded with the primary action and contains no filler or redundant prose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, read-only tool with a 100%-covered schema and strong safety annotations, the description covers the core operation, tab options, and return format. It could be more complete by noting behavior for non-existent IDs or how it differs from tab-specific endpoints, but given the low complexity, the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both id and tab are already documented in the input schema, including the valid tab values. The description's Args block merely restates the schema without adding new syntax, format, or behavioral details beyond what is structured. Baseline 3 applies since the schema performs the explanatory heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Récupère') and the resource ('les informations détaillées d'un(e) ressource par son ID'), making the tool's function unambiguous. The ID-based retrieval and optional tab parameter distinguish it from sibling search tools like boond_resources_search and tab-specific endpoints such as boond_resources_information or boond_resources_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (fetch full resource details by ID, optionally a specific tab) but does not explicitly state when to prefer this tool over tab-specific siblings or when not to use it. No alternatives or exclusions are named, so usage guidance is only implied by the ID-based scope and the optional tab parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds limited behavioral context beyond the participation scope and return type. It does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with the purpose front-loaded and a simple Args/Returns structure. Every sentence is necessary and there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with no output schema, the description covers the essential action, parameter meaning, and return type. It does not detail response fields, but that is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a generic entity ID description, while the tool description clarifies that the ID is specifically the resource ID. This adds meaningful context for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' with a clear object 'les projets' and a scope qualifier 'auxquels une ressource participe ou a participé'. This clearly distinguishes it from sibling tools like boond_contacts_projects or boond_opportunities_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a resource's projects using its ID) but does not explicitly state alternatives or exclusions. It is adequate but lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the read-modify-write mechanism ('lit la liste actuelle, en retire la référence ciblée, republie le reste') and warning 'Action irréversible'. This adds valuable context about side effects and data handling that annotations (destructiveHint) do not fully cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action verb, and includes a crucial warning. Every sentence earns its place with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter delete tool, the description covers the operation, the read-modify-write behavior, and the irreversibility warning. The lack of an output schema is not an issue since the tool is straightforward, but the description could have mentioned the response format or any prerequisites beyond verifying the ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (resourceId, referenceId) are already well-documented. The description adds context about references being embedded in the DT, but this is already present in the schema. No additional parameter semantics are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Supprime' (delete) and identifies the resource as 'référence (expérience professionnelle) du DT d'une ressource', clearly distinguishing it from sibling tools like create/update reference. It leaves no ambiguity about what action is performed and on what entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a reference needs to be removed, but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no direct comparison to sibling create/update tools, though the verb 'delete' makes the primary use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds only 'informations détaillées' (detailed information) and 'par son ID', which is minimal extra context. No contradictions with annotations, but no additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is appropriately front-loaded with the verb and resource. It contains no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description provides sufficient context to select and invoke it. It clearly states that it retrieves detailed information by ID. There is no output schema, but the description's 'informations détaillées' gives a general sense of the return value. It is not overly vague for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a 100% coverage description for the single parameter 'id', including type, pattern, and a description of what it is. The tool description does not add further semantic detail beyond repeating that the tool uses an ID, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' (retrieves) and identifies the resource 'rôle' and method 'par son ID'. This clearly distinguishes it from sibling tools like boond_roles_search, which searches for roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies that the tool is used when you have a role ID and need detailed information. It does not explicitly mention alternatives or exclusions, but the context is evident from the 'par son ID' phrasing, which indicates it is not for searching without an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no new behavioral traits beyond what the schema and annotations already convey. It is consistent but does not provide extra context such as authentication needs or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly one sentence, front-loaded with the action verb, and contains zero redundancy. Every word serves a purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter get-by-ID tool with strong annotations, the description is complete. It tells the agent what the tool does and by what key, while the schema handles parameter details. No output schema exists, but the phrase 'informations detaillees' sufficiently sets expectations. The sibling tool list reinforces the get/search/create/update/delete pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains 'id' as a numeric unique identifier. The description restates 'par son ID' without adding syntax or format details. With full schema coverage, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieve detailed information of an absence request by its ID. The verb 'recupere' is specific and the resource 'demande d'absence' is unambiguous. It naturally distinguishes from sibling search/create/update/delete tools by emphasizing retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use when you have a specific absence ID and need detailed information. It does not explicitly mention when not to use it or name alternatives, but the 'par son ID' makes the intended scenario evident. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it retrieves 'detailed information', which is consistent but not significantly more specific. No additional behavioral traits such as response format or error conditions are disclosed, but the annotations cover the essential safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the purpose. No unnecessary words or repetition; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval by ID with a single parameter and no output schema, the description provides all necessary context. The tool is a straightforward getter, and the description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter fully (numeric identifier). The description echoes 'by its ID' but adds no new semantic meaning beyond the schema, and schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' and clearly states the resource ('agence') and access method ('par son ID'). This clearly distinguishes it from the sibling search tool (boond_agencies_search) and other entity-specific get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool should be used when you have an agency ID and need its detailed information. It does not explicitly mention alternatives or exclusions, but the 'by ID' context makes the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds no additional behavioral context (e.g., response format or data included), but it does not conflict with annotations. The safety profile is fully covered by annotations, so a middle score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action, resource, and key parameter. There is no wasted wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter, strong annotations, and no output schema, the description is sufficient. It clearly conveys the tool's purpose without omitting critical information needed for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single id parameter with a clear description. The tool description adds no extra meaning beyond the schema, and the schema already defines the pattern and type. Given 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) with a clear resource 'calendrier' and scoping 'par son ID'. This distinguishes it from the sibling boond_calendars_search, which is implied to be for searching without an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'par son ID' clearly indicates the tool is for retrieving a specific calendar when the ID is known. Though no alternative is explicitly named, the intended use context is unambiguous, and the sibling search tool is clearly the alternative for finding IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds important context: the action is irreversible and confirmation may be requested. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action, and includes a clear warning. The Args section is redundant but not wasteful. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, good annotations (destructiveHint), and an output schema, the description is complete. It covers irreversibility and confirmation behavior, and no additional return-value details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'id' parameter 100%, including its pattern and description. The description repeats the parameter without adding meaningful new semantics, so it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with 'Supprime un(e) candidat de BoondManager' (deletes a candidate), using a specific verb and resource. This distinguishes it from sibling tools that delete other entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting candidates but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The irreversibility warning and elicitation note give some context but not enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and non-idempotent. The description adds valuable context about irreversibility and the potential for a confirmation prompt when the MCP client supports elicitation, going beyond the annotation flags. This extra behavioral detail justifies a score above the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences that front-load the core action and then append a necessary warning. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion operation with a single parameter and a full input schema, the description covers purpose, irreversibility, and confirmation behavior. The existence of an output schema further reduces the need to describe return values, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the input schema (100% coverage), so the description does not need to elaborate. The description adds no new parameter-specific information, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Supprime une facture' (deletes an invoice) and the system (BoondManager), clearly distinguishing this delete tool from sibling tools like get, update, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explicitly stating it deletes an invoice, and adds context about irreversibility and confirmation. However, it does not explicitly contrast this with alternatives such as boond_invoices_update or boond_invoices_search, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the documented effect of creating a placement, complementing the annotations (readOnlyHint=false, destructiveHint=false). It does not disclose potential side effects, validation rules, or return behavior, but given the annotations cover the safety profile, the additional context is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action and purpose, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter create tool with no required parameters and no output schema, the description covers the core purpose but leaves gaps: it does not specify the relationship between parameter groups nor mention the return value. The schema and annotations provide additional detail, making the description adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds conceptual meaning by explaining that the tool links either a candidate or a resource to either a project or an opportunity. This clarifies the parameter groups (candidateId/resourceId and projectId/opportunityId) beyond the individual schema descriptions, though it does not explicitly state required combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Crée') and resource ('positionnement'), and clarifies the purpose: placing a candidate or resource on a project or opportunity. This clearly distinguishes it from sibling tools like update/delete/search and from entity-specific creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: use this when placing a candidate or resource on a project or opportunity. It does not explicitly mention alternatives or exclusions, but the context is well-defined and implicitly guides the agent on when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable behavior beyond these: 'Seuls les champs fournis sont modifiés' indicates a partial update, and it explains how empty strings on startDate/endDate clear those fields. It also explains the folding of stateReasonTypeOf/stateReasonDetail into a nested stateReason object. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a bulleted args list, and a returns note. It is concise but not overly terse. The args list somewhat duplicates schema descriptions, but the added grouping of stateReason fields and the clearing behavior justify its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be detailed) and annotations, the description covers the key behaviors: partial update, field clearing, max comment length, and stateReason nesting. It does not mention error cases or prerequisites, but for a simple update with good schema/annotation support, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds semantic value by clarifying that stateReasonTypeOf and stateReasonDetail are combined into stateReason {typeOf, detail}, and that empty date strings are meaningful for clearing values. This goes beyond the individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Met à jour un positionnement existant dans BoondManager' with the specific PUT endpoint. It distinguishes from sibling tools (create/delete) by emphasizing 'existant' and by describing a partial update of fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when updating an existing positioning) but does not explicitly contrast it with alternatives like boond_positionings_create or boond_positionings_delete. No 'when not to use' guidance is provided beyond the implied scope of updating an existing record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, and non-destructive hints. The description adds value by flagging the API requirement for startDate/endDate, noting that state/type IDs come from boond_application_dictionary, and clarifying the default perimeter behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it opens with the tool's purpose, follows with a required-parameter warning in bold, then lists key filters and a behavioral note. Every sentence contributes meaningful information without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the return description is merely 'Données de reporting' without specifics. Given the tool's high complexity (19 parameters), the description would benefit from explaining result structure, pagination, or the interaction between period and periodDynamic, leaving gaps beyond what the schema already documents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description goes beyond this by highlighting key filter groups (perimeter, period, companiesStates, companies, maxCompanies, showPercentage) and adding the dictionary source note for integer IDs, which enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides reporting for companies, mentioning specific metrics (CA, marge, activité). It distinguishes itself from sibling reporting tools (e.g., boond_reporting_projects, boond_reporting_resources) by explicitly focusing on the 'sociétés' (companies) scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: it warns that startDate/endDate are required and explains that without a perimeter filter, the report covers the entire authorized scope. However, it does not explicitly mention when to use this tool versus the other reporting tools, nor does it provide exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that it returns a list ('Liste des avantages') and gives example categories, but does not discuss pagination, ordering, or potential missing data. This is minimal but acceptable given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the action in the first sentence, then lists the argument and return type. Every sentence earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema and strong annotations, the description fully covers what is needed: it names the input (resource ID), explains what is returned (list of advantages), and gives examples of what those advantages are. No further context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, fully describing the id parameter with pattern and description. The description repeats 'ID de la ressource' without adding additional syntax or formatting details, so it adds no value beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Récupère' and clearly identifies the resource as 'avantagages associés à une ressource', with concrete examples (tickets restaurant, mutuelle, véhicule, primes). This distinguishes it from sibling tools like positionings or projects, which serve different sub-entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need the list of advantages for a given resource ID. It does not explicitly name alternatives or exclusions, but the scope is unambiguous given the sibling tool names and the resource-specific focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the return payload: 'Données JSON complètes de la feuille de temps (jours, heures, statut, détails)', which clarifies what 'detailed' means. This adds value beyond the annotations, though it does not cover error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear Args and Returns sections. Every sentence serves a purpose: the first states the operation, the Args line defines the parameter, and the Returns line describes the output. No unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with a single parameter, good annotations, and no output schema, the description sufficiently covers the functionality and return content. It does not over-describe and is complete for an agent to decide to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the single parameter 'id': 'Identifiant unique de la feuille de temps'. The description repeats the same parameter text in the Args section, adding no new semantic information. The baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) and names the resource as 'informations détaillées d'une feuille de temps par son ID' (detailed timesheet information by ID), clearly distinguishing it from sibling tools like boond_timesheets_search (list) and boond_timesheets_create (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific timesheet ID and need full details, but it does not explicitly state when to use this tool versus alternatives like search or listing tools. No alternative tools are mentioned, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a significant behavioral trait: it returns a textual runbook that the model must subsequently execute by calling referenced Boond tools, meaning the tool itself does not directly modify data. It also discloses prioritization behavior (focusing on intercontract or short-term availability).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and then explains its relationship to the MCP prompt and the runbook output. It is concise but includes a slightly meta reference that could be trimmed; overall it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what the tool returns, and it does: a textual runbook for follow-up execution. It also explains the input scoping behavior (manager targeting) indirectly via schema, and mentions prioritization. However, it doesn't detail the runbook structure or specific Boond tools to be called, which could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters (manager_id and seuil_mois), each with detailed descriptions. The tool description does not add meaningful information beyond the schema for these parameters, so the baseline 3 applies. The prioritization mention loosely relates to seuil_mois but doesn't add syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: identifying resources with outdated, incomplete, or missing CVs/technical files, and prioritizing those soon available on the market. This is a specific verb+resource combination that distinguishes it from sibling workflow tools like boond_workflow_synthese_equipe or boond_workflow_pipeline_commercial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by stating it is the tool equivalent of the MCP prompt `cvs_a_mettre_a_jour`, and is useful for clients that don't handle MCP prompts correctly (e.g., claude.ai). This implies an alternative (use the prompt directly for capable clients), though it doesn't explicitly compare to other Boond workflow tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is clear. The description adds valuable behavioral context beyond annotations: it returns a runbook text that the model must execute by calling other Boond tools, and that output is sorted by fit ('Sortie classée par adéquation'). This is transparent about the indirection behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. Each sentence contributes: function, output format, usage context, equivalence to a prompt, and behavioral note. It is slightly longer than necessary but remains efficient for the complexity of a workflow tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description's explanation that the tool returns a runbook text is essential and provided. It also clarifies the multi-source nature and the intended usage phase. The description is complete enough for an agent to invoke the tool and anticipate the next steps, though it could elaborate on how the runbook is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter semantics are fully documented in the schema. The description reinforces the meaning of 'competences' as free-text and mentions the cross-source behavior, but it does not add new parameter-specific details beyond what the schema already provides. Base score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Recherche un profil correspondant à un mix de compétences libres, en croisant ressources internes et candidats.' It specifies the verb (recherche), the resource (profil), and the scope (multi-source). It also distinguishes itself from direct search tools by noting it returns a runbook to execute, and defines its relationship to a named MCP prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Utile en amont d'un staffing ou d'une opportunité non encore qualifiée.' It also explains when this tool is preferable ('utile pour les clients qui ne gèrent pas correctement les prompts MCP'). However, it does not explicitly exclude alternatives like direct resource/candidate search tools, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds an explicit irreversibility warning and explains that confirmation is requested when the MCP client supports elicitation. This adds behavioral context beyond the annotations, though it doesn't address cascading effects or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with purpose, and includes the warning and confirmation behavior. The Args list is minimal and necessary. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with annotations and output schema, the description covers purpose, irreversibility, and confirmation behavior. It lacks details on cascading deletions or error states, but these are not essential for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's Args section restates the id parameter, but the input schema already provides fuller information (unique, numeric pattern). With 100% schema coverage, the description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Supprime un(e) société de BoondManager' with the verb 'Supprimer' and resource 'société', distinguishing it from sibling delete tools for other entities (candidates, resources, opportunities). The title and description are fully aligned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear: use when deleting a company. The description does not explicitly mention alternatives, but the purpose is unambiguous. It also provides context about confirmation behavior via elicitation, which helps set expectations for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as safe, read-only, and idempotent. The description adds that the return value is a list of purchase orders, which is not covered by the schema or annotations. It doesn't contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short lines: a main sentence, an Args block, and a Returns line. It's front-loaded and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only listing tool, the description provides the essential purpose and return type. No output schema exists, so the 'Returns' line is valuable. It may lack pagination details, but that's acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the 'id' parameter with a description and regex pattern (100% coverage). The description's 'Args' section merely restates 'ID de la société' without adding extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves purchase orders for a specific company, using a specific verb and resource. It distinguishes itself from sibling tools like boond_contacts_orders or boond_orders_search by scoping to a company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's context is clear: it is intended to retrieve orders for a given company ID. It does not explicitly exclude alternatives, but the company-specific scoping provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait that only provided fields are modified (partial update), which goes beyond the annotations. Given that annotations already indicate idempotent and non-destructive behavior, the description adds value by explaining update semantics and return data, though it doesn't mention permissions or array field handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence for purpose and behavior, one sentence for return value. No redundant information or unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with 10 parameters, the description adequately covers the essential aspects: it states the update behavior, partial-update semantics, and return type. The schema covers all parameters, and annotations handle safety profile. It doesn't explain array field nuances but that's beyond typical description scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters are already documented in the schema. The description adds general awareness that only provided fields are updated but doesn't elaborate on specific parameters. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Met à jour' - updates) and resource ('facture existante' - existing invoice). It distinguishes from sibling tools like create, delete, get, and search by explicitly targeting updates. The addition 'dans BoondManager' provides system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Seuls les champs fournis sont modifiés' gives clear context about partial-update semantics, which is essential for proper usage. While it doesn't explicitly mention alternatives, the tool name and sibling list make it evident when to use this update tool versus create/get/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds the key behavioral detail that only provided fields are updated, which is crucial for understanding the tool's effect. It also discloses the return value. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the main action front-loaded. It includes a clear 'Returns:' line for output. No redundant information, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with 10 parameters and an output schema, the description is adequate: it explains the operation, partial update semantics, and return value. It does not explicitly note that only 'id' is required, but the schema shows this. The description is slightly minimal but complete given the structured metadata available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 10 parameters have descriptions in the input schema (100% coverage), so the schema already documents each field. The description does not add per-parameter details beyond the general patch behavior statement. This does not compensate further, but the schema coverage justifies a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing purchase order (bon de commande) in BoondManager. The verb 'Met à jour' and resource 'bon de commande existant' are specific, and 'Seuls les champs fournis sont modifiés' adds detail on partial update semantics. This distinguishes it from sibling tools like create, delete, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing order, with 'existant(e)' indicating it is not for creation. The partial update note ('Seuls les champs fournis sont modifiés') provides practical guidance on how to use it. However, it does not explicitly mention alternatives or exclusions, relying on tool names and context to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readOnly, idempotent, and non-destructive. The description adds useful context about partial update semantics (only supplied fields are modified) and states that updated data is returned, going beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two short sentences, front-loads the action, and includes a concise return statement. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with seven documented parameters, a non-required patch behavior, and an output schema, the description is sufficient. It would benefit from an explicit alternative/use-case statement but is not incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter has a description, so the schema carries most of the semantic weight. The description reinforces that only provided fields are modified, which applies to all parameters, but adds no parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Met à jour' and identifies the resource as 'un(e) projet existant(e) dans BoondManager', making the operation unmistakable. It also notes that only provided fields are changed, which further distinguishes it from create/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying existing projects and not for creation ('existant(e)'), but it does not explicitly name alternatives such as boond_projects_create. It does provide clear partial-update guidance with 'Seuls les champs fournis sont modifiés'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minor context by listing absence types (congés, RTT, maladie) and the return type (Liste des demandes d'absences), but does not disclose any additional behavioral traits such as pagination, status filtering, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a purpose line followed by Args and Returns sections. It contains no unnecessary filler and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, no output schema, and strong annotations. The description provides enough to understand its purpose and return type. It could be more explicit about the scope of 'absences' (e.g., statuses, date ranges), but for a straightforward read-only resource report, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter, and the schema describes 'id' as a generic numeric entity ID. The description adds specificity by stating 'ID de la ressource', clarifying that the ID refers to a resource entity, which goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Récupère les demandes d'absences d'une ressource' clearly states the tool's function with a specific verb (Récupère) and resource (demandes d'absences d'une ressource). It also lists examples (congés, RTT, maladie...) and is distinguishable from siblings like boond_absences_search because it targets a specific resource's absence requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is clear: use it to get absence requests for a specific resource identified by 'id'. It implies when to use it (resource-specific reporting) but does not explicitly mention alternatives or exclusion cases (e.g., when to use boond_absences_search instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds useful behavioral details beyond annotations: the month/year defaults to current values if omitted, and the return format is summarized as a list with days/hours and status. This adds transparency without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line summary followed by a concise Args list. Every sentence is informative and sparse, with no unnecessary fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description provides a return summary ('Liste des feuilles de temps... avec jours/heures et statut'), which covers the essential output. For a simple read-only tool with three documented parameters, this is sufficiently complete. Minor details like pagination or sorting are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% parameter description coverage, so the baseline is 3. The description repeats the parameter names, types, and defaults but does not add extra semantics like examples, constraints, or relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) and clearly identifies the resource type (timesheets/times reports) and the primary parameter (resource ID). It also distinguishes this tool from broader timesheet tools by specifying resource-scoped retrieval with optional month/year filters, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context: when you need timesheets for a specific resource by ID, with optional month/year filtering. It does not explicitly name alternatives or exclusion criteria, so it falls short of a 5, but the usage context is clear and not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context: the tool returns a textual runbook that the model must then execute by calling referenced Boond tools, clarifying that this is an orchestration/planning tool rather than a raw data fetch. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the purpose, the second provides context (MCP equivalence) and the output behavior. Every clause contributes useful information without unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter workflow tool with no output schema, the description explains the type of output (runbook text) and the required follow-up action (call referenced Boond tools), while naming the included domains. It could be more explicit about runbook structure or which tools are referenced, but it is sufficient for selection and initial invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `semaine` is fully described in the schema (100% coverage), including an example and default value. The description does not add further parameter-level semantics beyond mentioning 'cette semaine', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Compile') and specifies the exact scope: a weekly view of past/upcoming events for the user and their team, covering opportunities, projects, absences, and CRA. It also distinguishes itself by framing the tool as the tool-based equivalent of the MCP prompt `recap_hebdo`, separating it from sibling workflow tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use context: it is an 'équivalent en outil' of the MCP prompt `recap_hebdo`, useful for clients that do not manage MCP prompts (e.g., claude.ai). It does not, however, name alternatives or say when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the readOnlyHint annotation, the description adds important behavioral context: it handles illegible fields by asking the user, it never invents receipt amounts, and it returns a text runbook that the model must later execute. The only slight ambiguity is the phrase 'crée la ligne de frais' against the readOnlyHint, but the following sentence clarifies that the tool actually returns a runbook to be executed. No hard contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, French-first, and front-loads the core purpose. It includes necessary workflow details, user validation, and actual output without unnecessary fluff. The short note about MCP client compatibility earns its place by explaining why this tool exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description clearly states the output is a runbook to execute by calling Boond tools. It covers input, validation rules, no-invented-amount behavior, and the downstream action. It does not detail the runbook format, but for a workflow tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the input schema (100% schema description coverage), including defaults, resolution logic, and use of alternative search tools. The main description itself does not add significant extra parameter-level semantics, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs: extracts expense data and creates the corresponding expense line (via a follow-up runbook). It clearly states the input (receipt photo/PDF), the scope (BoondManager expense report), and uniquely identifies the workflow, distinguishing it from other sibling workflow tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use it: when a photo or PDF of a receipt is attached. It also gives a strong behavioral guideline: validate explicitly with the user before proceeding, and it positions itself as a tool equivalent to the MCP prompt for clients that don’t handle MCP prompts well. It does not explicitly list exclusions or direct alternatives, but the conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which covers the basic safety profile. The description adds significant behavioral value: the response is an embedded MCP resource (base64 for binaries, plain text for text files), the 5MB size limit, and the non-obvious ID suffix requirement with a warning about truncated IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it leads with the core purpose, then covers ID sourcing, response format, and limitations in separate sections, ending with a parameter list. Every sentence carries useful information without redundancy or excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the key operational aspects: how to obtain IDs, the response format (base64/plain text), the 5MB limit, and the required suffix. It does not mention error cases (e.g., not found, invalid ID) or authentication, but for a simple read operation this is adequate and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by adding the crucial instruction to use the ID 'tel quel, suffixe compris' and explicitly warns that a numeric-only truncated ID is invalid, with an example ('123_resume'). This is valuable semantic guidance on top of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Télécharge le contenu d'un document BoondManager ... par son ID', using a specific verb (download) and resource (document content) with a clear identifier-based method. It also enumerates document types (CV, justificatif, contrat, facture), distinguishing it from sibling tools like boond_documents_create and boond_documents_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: 'Taille max: 5 Mo — à n'utiliser que lorsque le contenu du fichier est réellement nécessaire (un CV en base64 occupe beaucoup de contexte)' warns when the tool should be used and why. It also explains how to find document IDs, but it does not explicitly name alternative tools (e.g., metadata endpoints) as substitutions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing little signal, so the description carries the burden. It discloses useful behaviors: creation always goes to 'savedAndNoValidation' state, amountIncludingTax is TTC and tax is a rate with net/VAT recalculated server-side, and the prerequisite dependency. The write nature (readOnlyHint=false) is consistent with a create tool - no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded: purpose first, then the critical prerequisite warning, then line-level semantics, state behavior, and return value. Every sentence earns its place - the 422 warning and TTC/tax clarification prevent real errors. Slightly dense but no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex create tool (9 top-level params plus a 13-field array), and with all-false annotations, the description must cover cross-cutting concerns. It addresses the external dependency on boond_expenses_default, the TTC/tax recalculation model, and the non-controllable state. Output schema exists so return values are covered. Adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: the month×resource relationship, that term follows YYYY-MM, that tax is a rate not a mount, that expenseTypeReference comes from boond_expenses_default (not boond_application_dictionary), and that omitting actualExpenses creates an empty report. This adds genuine value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource with scope: 'Crée une note de frais dans BoondManager' and adds the defining constraint 'une note de frais = un mois (term) × une ressource'. This clearly distinguishes it from sibling tools like boond_expenses_search, boond_expenses_get, boond_expenses_update, and boond_expenses_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit prerequisite guidance: 'Appeler boond_expenses_default d'abord' with the named tool and concrete consequence (422 error without it). Context for when to use is clear (creation flow), though it does not explicitly state when not to use it or contrast with update/delete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes that the action is irreversible and that a confirmation may be requested if the MCP client supports elicitation. This adds valuable behavioral context beyond the destructiveHint annotation, which only indicates destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-load the core purpose, then add a warning about irreversibility and confirmation. Every sentence adds value with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with an output schema and annotations, the description covers essential behavior: the action itself, irreversibility, and confirmation flow. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with a clear description and pattern. The tool description adds no additional parameter semantics, so the baseline of 3 applies for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (deletes) on a specific resource (purchase order from BoondManager), clearly distinguishing it from sibling get/update/search tools. The verb 'Supprime' and resource 'bon de commande' make the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deleting a purchase order and warns about irreversibility, but does not explicitly mention alternatives or when-not-to-use conditions. It lacks explicit guidance such as 'use boond_orders_update to modify instead' or 'do not use if the order is linked to invoices.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable context by stating 'Seuls les champs fournis sont modifiés' (partial update) and that it returns the updated resource data. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences plus a 'Returns' line. It front-loads the core purpose and partial-update behavior, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a flat update tool with 10 parameters fully described in the schema, an output schema, and good annotations, the description is complete. It conveys the essential behavior (partial update, returns updated data) without needing to explain every field or return value since those are already structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the description does not need to explain parameters. The description itself does not add any parameter-specific meaning beyond the schema, which is the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Met à jour un(e) ressource existant(e)' (Updates an existing resource), which identifies both the action (update) and the resource (resource). This distinguishes it from sibling tools like boond_resources_create, boond_resources_delete, and boond_resources_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for modifying existing resources ('existant(e)') and notes that only provided fields are modified, giving clear context on when it applies. However, it does not explicitly name alternative tools or state when not to use it, so it misses the 'alternatives' criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds valuable behavioral context beyond annotations by warning that omitting startMonth/endMonth or using YYYY-MM-DD format triggers a 422 error. This is useful API-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, a warning, a bulleted parameter list, and a return note. It is not overly verbose, though the parameter list partially duplicates schema information. The warning and examples earn their place, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description provides sufficient context: it names the resource, lists required and optional parameters, and states that it returns a list of matching timesheets. Given the simple nature of the operation and comprehensive schema/annotations, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, patterns, and defaults, so the baseline is 3. The description adds extra value by explicitly marking startMonth and endMonth as required and emphasizing the YYYY-MM format caveat, which echoes the schema but reinforces the critical constraint. It also lists examples for date formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Recherche des feuilles de temps (CRA mensuels)' which clearly identifies the action (search) and resource (monthly timesheets/CRA). This distinguishes it from sibling tools like boond_timesheets_get or boond_timesheets_create, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: for searching monthly timesheets in BoondManager. It highlights the mandatory parameters and warns about 422 errors with wrong formats. However, it does not explicitly mention alternatives or when not to use this tool, such as when retrieving a single timesheet by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing key behaviors: sorting by availability date, proposing priority profiles, and returning a runbook text for the model to execute. It also explains that competencies are mapped via a dictionary, adding meaningful operational context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences that efficiently convey purpose, options, behavior, and usage context. Every sentence adds value, though it could be slightly tightened. The front-loading of the main verb and resource helps quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description's mention of a runbook text return is crucial and covers the most important missing information. The description also covers sorting, filtering, and scope. It omits specifics about runbook format or edge cases, but given the annotations and rich schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds only marginal semantic value by referring to 'compétences (texte libre)' and 'périmètre', but these concepts are already fully described in the schema. It does not significantly clarify parameter interpretation beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: finding internal resources available for staffing within a date window, with optional filters and sorting. It explicitly distinguishes itself from other tools by positioning as the tool-based equivalent of the MCP prompt `staffing_disponible`, making its unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool: as an alternative to the MCP prompt staffing_disponible, particularly for clients that handle MCP prompts poorly. It gives a clear usage context and the return behavior (runbook), but does not explicitly exclude other siblings or provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds PATCH-like behavior with 'Seuls les champs fournis sont modifies', which is not covered by annotations. It also reinforces that the absence must already exist. Given the annotations already declare non-readonly, non-destructive, and idempotent, this extra context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short French sentences, front-loaded with the action verb 'Met a jour'. No filler or repetition, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 5 parameters, 1 required, no output schema, this description covers the essential behavior. It could mention error cases or response format, but the annotations cover the safety profile, making it adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is individually described. The description adds the crucial semantic that omitted parameters are left unchanged, clarifying that optional fields are not reset. This builds on the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Met a jour une demande d absence existante' (Updates an existing absence request), clearly identifying the action (update) and resource (absence). 'Seuls les champs fournis sont modifies' further specifies partial update semantics, distinguishing it from create/delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying an already-existing absence, and that only provided fields are changed. It does not explicitly mention alternatives like create or delete, but the 'existing' qualifier gives clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context about the returned data (profile, permissions, agency) and specifies the return format (JSON). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and includes a brief return note. No fluff or redundant statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description is adequate: it explains what is returned and provides examples. Without an output schema, it gives a clear idea of the payload, though a full field list is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything. The description does not need to explain parameters. Baseline for 0 params is 4, and no additional semantic info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the currently connected BoondManager user's information, with examples (profile, permissions, agency). It uses a specific verb (récupère) and resource, distinguishing it from other user/resource tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is for the current authenticated user. However, it does not explicitly mention when to use it versus alternatives (e.g., searching for users). No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the mutation and safety profile. The description adds valuable context beyond annotations: the partial-update semantic ('Seuls les champs fournis sont modifiés') and the return value ('Données mises à jour'). This is meaningful behavioral disclosure without violating annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a return line. It front-loads the action with a specific verb and resource, then adds the critical partial-update detail. Every sentence serves a purpose with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, 1 required, full schema coverage, and an output schema, the description covers the core purpose, the partial-update behavior, and the return value. Annotations handle idempotency and destructive hints. It does not mention error cases or authentication, but these are not essential for a well-specified update operation, so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds the key insight that only provided fields are modified, which is a parameter-level behavior not captured in the schema. This clarifies how to interpret all optional parameters and justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Met à jour un(e) candidat existant(e) dans BoondManager' (Updates an existing candidate). It uses a specific verb and resource, and explicitly mentions 'existant(e)' to distinguish from create/delete. This differentiates it from sibling tools like boond_candidates_create and boond_candidates_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for updating an existing candidate, implying it should not be used for creation or deletion. It also specifies partial-update behavior ('Seuls les champs fournis sont modifiés'), which guides when and how to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, idempotent write operation. The description adds valuable behavioral context by stating that only provided fields are modified and returns the updated company data, which goes beyond what the annotations convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three short segments: purpose, partial update behavior, and return value. Every sentence earns its place, and the critical information is front-loaded. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and robust annotations, the description is sufficiently complete. It covers the operation type, the partial update semantics, and the return value. It does not mention error handling or specific prerequisites, but these are not essential for an update tool with a well-documented schema and safety hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions. The description adds meaningful semantic context by explaining that the tool performs a partial update (only supplied fields are changed), which helps the agent understand that optional parameters are truly optional and that omitting them preserves existing values. This enriches the parameter understanding beyond raw schema labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Met à jour' (updates) with the resource 'société existante' (existing company), clearly distinguishing it from create/delete/get tools. It also adds the key behavior that only provided fields are modified, further clarifying its purpose as a partial update tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for updating an existing company, implying it is not for creation or deletion. However, it does not explicitly mention alternatives like boond_companies_create or boond_companies_delete, nor does it state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose idempotency and non-destructiveness. The description adds the crucial partial-update behavior, explaining that only supplied fields are changed—valuable beyond the annotations. It also states the return value, though that is redundant given the output schema, but does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences cover the action and a key behavioral nuance, plus a return-value note. It is front-loaded with the main verb and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with an output schema, the description is sufficiently complete. It conveys the core behavior (update existing contact, partial update) and return type. It does not mention error handling or prerequisites, but these are typically implied by the schema and context, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100%), but the global statement 'Seuls les champs fournis sont modifiés' adds important semantics for optional parameters, clarifying that omitted fields are left unchanged. This goes beyond the individual schema descriptions, which are just field labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing contact in BoondManager, using the specific verb 'Met à jour' and resource 'contact'. The additional note that only provided fields are modified further clarifies the tool's exact scope, distinguishing it from create or delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing contacts, and the partial-update statement ('Seuls les champs fournis sont modifiés') gives clear guidance on how to call the tool (send only the fields to change). However, it does not explicitly name alternative tools (e.g., create/delete) or state when not to use it, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, but description adds meaningful behavioral details: the API downloads the file itself, no local file is read, and parsing=true triggers Boond AI analysis. It also discloses the return value (metadata with ID). This goes beyond the annotations and helps the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the main action front-loaded. It uses three short paragraphs: action/behavior, typical use cases, and return value. Every sentence adds relevant information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with a rich input schema and an output schema, the description covers the essential context: what it does, typical scenarios, and return metadata. It does not mention error cases or permissions, but given the annotations and schema, it is sufficiently complete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by linking parameters together: parentType=candidateResume with parsing=true for CV analysis, and examples like expensesReport. This clarifies the intended use of parameters beyond their individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Attache un document à une entité BoondManager à partir d'une URL' with a specific verb and resource. It distinguishes from sibling tools like boond_documents_get/delete by being the create operation. Typical use cases further clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit typical use cases: attaching a CV to a candidate with parsing=true, a receipt to an expensesReport, and documents to projects/companies. It also clarifies the URL-based behavior and the parsing option, giving clear context for when to use it. Does not explicitly state when not to use it, but the examples serve as strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds meaningful context about partial update behavior and states that updated data is returned. This complements the annotations without contradicting them, though it omits details like validation or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences plus a returns clause, with no filler. It is front-loaded and every sentence serves a purpose: what it does, how it behaves, and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with complete schema coverage, an output schema, and annotations, the description covers the essential aspects: purpose, partial-update behavior, and return value. It is adequate, though it could be slightly more complete by mentioning error cases or prerequisites like the ID needing to exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a valuable cross-cutting semantic: only provided fields are modified, clarifying that all parameters except id are optional and that omitted fields remain unchanged. This goes beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Met à jour un(e) produit existant(e) dans BoondManager' – a specific verb ('Met à jour'), the resource ('produit existant'), and the system ('BoondManager'). This distinguishes it from sibling tools like create, delete, search, or get for the same entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it (updating an existing product) and includes the valuable partial-update guidance 'Seuls les champs fournis sont modifiés'. However, it does not explicitly name alternatives or state when-not-to-use, falling 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavioral context beyond annotations: it specifies the endpoint /resources/{id}/technical-data, explains that only explicitly provided fields replace the target reference, and assures that other fields and references remain intact. This goes well beyond the basic safety hints (idempotent, non-destructive) and clarifies side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, the first states the core behavior and partial update semantics, the second gives a typical use case. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a partial update tool with no output schema, the description covers the endpoint, update semantics, and a sample use case, which is sufficient for an agent to invoke it correctly. While it doesn't describe return values, that is not required given the absence of an output schema and the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions specific parameters (startMonth/startYear/endMonth/endYear) and affected fields in the use case, but does not add significant new meaning beyond the schema. The schema already documents all parameters, so the description's contribution is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'met à jour une référence existante' (updates an existing reference), with a specific endpoint and partial-update semantics. It distinguishes itself from sibling create/delete tools by focusing on update behavior and the read-modify-write nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical use case (completing date fields without touching other fields), which implies when to use this partial update tool. It does not explicitly exclude alternatives, but the context is sufficient for an agent to infer appropriate usage compared to create/delete or full technical-data update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent déjà que l'outil est en lecture seule et idempotent. La description ajoute que l'outil ne renvoie pas directement les candidats mais un runbook texte à exécuter avec d'autres outils, ce qui est un comportement clé.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
La description est concise, composée de trois phrases qui apportent chacune une information nécessaire : l'action, l'équivalence MCP, et le retour d'un runbook. Aucune redondance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
La description explique l'entrée (opportunité avec critères) et la sortie (runbook texte), ainsi que le mécanisme d'exécution. Elle reste un peu vague sur le contenu exact du runbook ou les outils référencés, mais c'est suffisant pour une vue d'ensemble.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma documente complètement le paramètre opportunity_id, y compris l'acceptation d'un ID ou d'un intitulé avec résolution automatique. La description n'ajoute pas de détails supplémentaires sur le paramètre, mais elle le mentionne implicitement via 'À partir d'une opportunité'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La description indique clairement que l'outil identifie les candidats actifs correspondant à une opportunité en se basant sur ses outils, expertise et mobilité, et précise qu'il retourne un runbook à exécuter. Elle le distingue des outils de recherche directe en le présentant comme un équivalent de prompt MCP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description précise le contexte d'utilisation (clients ne gérant pas correctement les prompts MCP) et explique que le modèle doit exécuter le runbook. Cependant, elle ne compare pas explicitement avec d'autres outils de workflow similaires, comme boond_workflow_recherche_profil_competences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: the tool returns a text runbook that the model must subsequently execute by calling other Boond tools. This goes beyond the readOnlyHint and idempotentHint annotations, which already indicate a safe read-only operation, and adds valuable context about the expected follow-up actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: three sentences that front-load the main purpose, then add the highlight feature, the MCP equivalence, and the runbook output. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description appropriately explains the return value (a text runbook) and the required follow-up. It also mentions the optional filtering parameters via the schema. A bit more detail on the runbook format could enhance completeness, but the current description is sufficient for the model to understand the tool's purpose and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both parameters (`manager_id` and `horizon_jours`), including default values and resolution logic. The description itself does not add additional parameter semantics beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing resources whose assignments end soon and highlighting those without a confirmed next step, to anticipate repositioning. It also distinguishes itself from sibling workflow tools by mentioning the MCP prompt equivalence and the runbook output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is the tool equivalent of the MCP prompt `fin_de_mission` and is useful for clients that do not handle MCP prompts, such as claude.ai. It also implies when to use it (for repositioning planning), but does not explicitly exclude other tools or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals a critical behavioral trait: it returns a runbook text that the model must then execute by calling referenced Boond tools, rather than returning the analysis directly. This goes beyond the annotations (readOnly/idempotent) and is essential for correct usage. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, context/usage, and output behavior. It is concise, front-loaded, and avoids redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a workflow meta-tool, the description adequately explains the output (runbook) and what to do with it (execute referenced Boond tools). It lacks details about the runbook's structure or error handling, but this is not critical for an agent to use it correctly. The absence of an output schema is partially compensated by the explicit description of the return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds minimal semantic value by mentioning 'closing prévu dans la période donnée', which links the date parameters to the analysis scope, but it doesn't elaborate on parameter formats or behaviors beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes commercial opportunities with closing in a given period, breaking down by state, weighted revenue, and top opportunities. It also distinguishes itself as a workflow equivalent to an MCP prompt, which sets it apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this tool is useful for clients that don't handle MCP prompts correctly (e.g., claude.ai), which gives clear context on when to use it. It also explains the output is a runbook to execute, but it doesn't explicitly mention when not to use other tools or provide alternative comparisons beyond the MCP prompt context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already include destructiveHint=true, the description adds '⚠️ Action irréversible' (irreversible action) and explains that a confirmation may be requested when the MCP client supports elicitation. This provides valuable context about consequences and user interaction that goes beyond the structured annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, followed by essential warnings. Every sentence contributes useful information, and the Args section, while redundant, does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description covers the purpose, irreversibility, and confirmation behavior. An output schema exists, so return values need no explanation. The description is complete given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the sole parameter 'id' with complete coverage (100%). The description repeats the parameter in an Args block but adds no new meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Supprime' (delete) and explicitly identifies the resource as 'projet de BoondManager', making the tool's purpose unmistakable. This clearly distinguishes it from sibling tools that update, create, or delete other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for deleting a BoondManager project, and the tool name reinforces this. However, it does not explicitly mention alternatives or exclusions (e.g., 'for modifying a project, use boond_projects_update'), so it falls short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond annotations: it returns a runbook text rather than direct data, which the model must execute by calling other Boond tools. This is significant for a read-only tool, as it explains the indirect nature of the operation. It also emphasizes the 360° aggregation, adding value beyond the standard readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that efficiently cover purpose, use case, and behavior. It opens with a clear summary, then adds contextual and operational details without redundancy. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a workflow tool with one parameter and no output schema, the description is complete. It explains what the tool returns (a runbook), how to use it (execute the referenced tools), and its intended scenario (MCP-incapable clients). No essential context is missing for the agent to decide and act.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete documentation for the sole parameter `resource_id`, including both accepted formats and automatic resolution via `boond_resources_search`. The description itself does not add any additional parameter semantics; since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific scope: 'Vue 360° d'une ressource : info, profil technique, positionnements, absences, CRA récents.' It identifies the resource type and the aggregated data categories, distinguishing it from simpler get tools. It further differentiates from siblings by noting it's an equivalent of an MCP prompt, making it a unique workflow tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'utile pour les clients qui ne gèrent pas correctement les prompts MCP, ex: claude.ai'. It also instructs how to handle the output ('Retourne un runbook texte que le modèle doit ensuite exécuter'). However, it does not explicitly state when not to use it or provide direct alternatives among the sibling tools, falling short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: the mandatory dependsOn relation, the positioningId requirement for certain action types (with error 422 note), the companyId-only-with-contactId constraint, and the return of the created action with its ID. This extends well beyond the minimal annotations (all false) to give agents actionable expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, an args list, and a return statement. It is moderately long but every line adds value, without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 12 parameters and no output schema, the description covers the core purpose, parameter constraints, API caveats (positioning error), and return behavior. It provides sufficient context for an agent to invoke it correctly, even if it lacks full examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds crucial relational semantics not visible in the schema: exactly one of contactId, candidateId, resourceId, opportunityId, or projectId is required, companyId pairs only with contactId, and positioningId is API-required for positioning-linked action types. This elevates it above the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new action (call, email, appointment, note) in BoondManager, specifies the attachable entity types (contact, candidate, resource, opportunity, project), and includes the mandatory dependsOn relation. This distinguishes it from search/get/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: creating an action tied to any supported entity, and it notes the mandatory dependsOn relation. However, it does not explicitly name alternative tools or exclusion scenarios, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond annotations: it notes that results are a paginated list, that filters are server-side, and that company type must be inferred via the detail endpoint. There is no contradiction with annotations, but no additional safety or rate-limit info is given, keeping the score at 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than a minimal one-liner, but it is well-structured with a clear purpose line, bulleted use cases, a note, and a returns line. Every section earns its place given the tool has 22 parameters and requires substantial guidance. It could be slightly tighter, but the organization makes it scannable and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a 100% schema description, good annotations, an output schema, and 22 parameters, the description is remarkably complete. It covers the main use cases, parameter relationships, a critical limitation (typeOf), and directs to the appropriate detail tools. No major information gap is evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by showing common parameter combinations (e.g., perimeterDynamic: ['data'] for 'Mes comptes') and the special ID syntax (keywords: 'CSOC<id>'), which are not evident from the schema alone. It groups related parameters by use case, adding interpretation beyond the raw descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Recherche des sociétés (clients, prospects, fournisseurs…) dans BoondManager avec filtres serveur', which clearly states a specific verb (recherche) and resource (sociétés), and distinguishes from the sibling get tool by noting that detail is obtained separately. It also clarifies search behavior (server filters, pagination) and a key limitation (no typeOf filter), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Cas d'usage courants' section provides concrete examples for common scenarios (mes comptes, états, période, recherche par ID), which is explicit when-to-use guidance. The description explicitly directs users to boond_companies_get for detail and warns about the missing typeOf filter, effectively stating when not to rely solely on this search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (which only provide negative hints) by disclosing the read-modify-write behavior, the embedded nature of references, and the leading-zero date rejection pitfall. This is valuable context that helps the agent anticipate side effects and constraints. No contradiction with annotations detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose, an important behavioral warning, required fields, date edge cases, and an alternative tool. Each sentence serves a distinct purpose, and warning emojis efficiently highlight critical pitfalls.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly complete for a create tool: it explains the embedded sub-object nature, the read-modify-write flow, required parameters, date constraints, and the relationship to the update tool. It omits only return-value details, but no output schema exists, so this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions already document all parameters and constraints, including min/max values and the leading-zero warning. The description only summarizes required fields and date format notes, adding marginal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a professional experience (reference) attached to a resource's technical data (DT), which is a specific verb + resource + scope. It also distinguishes itself from sibling tools by explicitly directing users to boond_resources_reference_update when completing an existing reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool vs. the alternative: 'Pour compléter une référence existante, utiliser boond_resources_reference_update pour ne pas dupliquer.' It also explains the underlying read-modify-write flow, helping users understand why this tool is for creating new references and not for editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral traits not covered by annotations: partial PUT semantics, preservation of relations (dependsOn, positioning, calendar sync), and that text replaces existing content rather than appending. It also warns against a destructive alternative. This is substantial added context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary, a warning note, a clear parameter list, and a return statement. It is appropriately sized for six parameters and every sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full input schema, output schema, and annotations, the description still adds key operational context (partial update, no relations sent, calendar preservation) that structured data does not convey. The tool is fully specified and the description rounds out the behavioral story.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter including typeOf's dictionary reference and date formats. The description restates the parameter list and adds the general partial-update note, but does not provide significant new meaning per parameter beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Met à jour une action existante' (updates an existing action) in BoondManager, specifying it is a partial PUT where only provided fields are modified. This distinguishes it from create/delete tools and explicitly names the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: it is 'Idéal pour ajouter un compte-rendu sans casser l'agenda' and contrasts directly with 'delete + recreate' which would delete the calendar event. It also explains that no relations are sent, preserving dependencies and scheduling, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readonly and idempotent annotations, the description explains caching (TTL 1h, configurable), subtree extraction behavior, return shape, and the isError flag for invalid paths. This gives an agent essential context about data freshness and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, followed by logical sections for path pattern, examples, and a critical note. While the example list is extensive, each example is instructive and the warning about legacy syntax justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with no output schema, the description covers return values, error behavior, caching, and path semantics thoroughly. It is complete enough for an agent to invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description greatly enriches the minimal schema by explaining that dictionaryType is a dotted path relative to 'data' and listing numerous valid examples. It also explicitly corrects the outdated slash syntax found in the schema, preventing likely misuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a BoondManager reference dictionary, listing specific categories and the dedicated endpoint. This distinguishes it from all sibling entity-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for any reference data lookup and provides explicit guidance on correct path syntax, including a warning about the invalid legacy slash format. It does not explicitly exclude alternative entity tools, but none serve this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds critical behavioral context beyond these annotations: it returns a runbook text that the model must then execute by calling referenced Boond tools. This is a key behavioral trait that would otherwise be unknown, and it also mentions grouping by company and optional filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences: main functionality, optional filter, MCP equivalence/usage, and runbook output. Every sentence earns its place with no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description explains the return value is a runbook text and what the model should do with it. Combined with the annotations (read-only, idempotent) and the full parameter schema, the description provides complete context for a read-only workflow tool: what it does, when to use it, and what to expect in the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage: the sole parameter `society_id` has a full description explaining it accepts a numeric ID or company name with auto-resolution via `boond_companies_search`. The tool description only reaffirms optionality ('Optionnellement filtrable sur une société spécifique') without adding further meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Liste les factures impayées avec date d'échéance dépassée, regroupées par société.' This is a specific verb+resource+scope, listing unpaid invoices with overdue due dates, grouped by company, and optionally filtered by a specific company. This distinguishes it from sibling workflow tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is the tool equivalent of the MCP prompt `factures_a_relancer` and is useful for clients that do not handle MCP prompts well (e.g., claude.ai). This provides clear when-to-use guidance and names an alternative (the MCP prompt), satisfying the 'explicit when/when-not/alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses a critical behavioral trait: it 'Retourne un runbook texte que le modèle doit ensuite exécuter en appelant les outils Boond référencés', indicating this is not a simple data return but an orchestration step. It also explains the default manager_id behavior, adding substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with the primary purpose, then covers fallback behavior, usage context, and return type in two sentences. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately describes the return value ('runbook texte') and instructs the model on next steps. It also provides background on the tool's origin (MCP prompt equivalence) and parameter defaults, making it complete for a workflow tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with clear descriptions, so the baseline is 3. However, the description adds meaningful semantic detail about manager_id: if omitted, it uses the current user as manager, which clarifies default behavior beyond the schema's simple description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Produit un état d'équipe' and enumerates specific outputs ('qui est sur quoi, qui est absent, qui est disponible'), giving a precise verb+resource combination. It also distinguishes itself from sibling workflow tools by mentioning its equivalence to the MCP prompt `synthese_equipe`, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, specifically for team synthesis and as a fallback for clients that mishandle MCP prompts (e.g., claude.ai). It mentions an alternative (the MCP prompt itself) but does not explicitly state exclusions or when not to use it, so it stops 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: the returned data nature, the per-agency definition of expense types, and the constraint that the API rejects non-imputable pairs. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with a clear purpose statement, usage guidance, argument list, and return summary. Every sentence adds value, and it is well-structured with bold highlights for key terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple reference types, constraints, and no output schema), the description covers all necessary context: what it returns, when to use it, important constraints, and how the result should be used in boond_expenses_create. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds nuance: it clarifies agencyId is optional and forces the agency, and explains the role of term in determining imputability. It also ties the parameters to the function purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the necessary references for entering an expense note, listing the specific data (agency, currency, expense types, mileage scales, imputable pairs). It explicitly distinguishes itself from boond_expenses_create by being a prerequisite retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this BEFORE boond_expenses_create, explains why (types are per agency, not in application_dictionary), and warns about the mandatory projectId/deliveryId and API rejection of non-imputable pairs. This provides clear when-to-use and why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds behavioral details beyond these: default keyword search behavior (resumeTd), AND/OR logic for tools via '#AND#', perimeterDynamic shortcuts, and the requirement to combine coordinates/location with geoDistance. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is well-structured with bullet points and bold category headers. It front-loads the core purpose and each section covers a coherent filter group. For a tool with 36 parameters, this level of detail is warranted and every sentence contributes practical guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all major filter categories, pagination, sorting, and return type, and directs users to complementary tools for candidate details. Combined with the 100% schema coverage and output schema, it provides complete guidance for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description substantially enriches parameter meaning with real-world usage examples: perimeterDynamic values for 'Mes candidats', perimeterManagersType main/hr distinction, languages format ('langueId|niveauId'), tools AND/OR syntax, and period combinations. It also links parameters to dictionary lookups, adding practical value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Recherche des candidats dans BoondManager avec filtres serveur.' It clearly identifies the tool as a server-filtered candidate search, distinguishes it from boond_candidates_get by recommending that tool for detail, and states the return type (paginated list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage contexts for common scenarios (perimeter, states, technical profile, sourcing, period, keyword search, geolocation) and explicitly mentions alternatives for detail retrieval ('Utiliser boond_candidates_get ou les outils d'onglets pour le détail'). It also references supporting tools like boond_application_dictionary and boond_application_current_user for ID lookups, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the rich annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses non-obvious behavior: server-side filtering, paginated returns, OR-by-default with the '#AND#' trick for combining filters, the typesOf naming gotcha (⚠️ with 's'), and keyword format conventions (CSOC prefix, NOM#PRENOM). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded (purpose in the first sentence) and uses a scannable bullet structure organized by use case with bolded parameter names and inline code. While long, every section earns its place for a 27-parameter search API, and it avoids restating each parameter's schema description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool (27 optional params, no required params), the description covers the essential combination patterns, sort behavior, return type, and pointer to detail tools. With annotations and output schema covering safety and return structure, the description focuses on the non-obvious semantics an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description adds meaning beyond schema descriptions: the 'CSOC<companyId>' convention for company-scoped searches, the 'data' shortcut for perimeterDynamic, the NOM#PRENOM format for fullName, dictionary references (setting.state.contact, setting.typeOf.contact), and cross-parameter combination patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb+resource: 'Recherche des contacts (interlocuteurs clients / prospects) dans BoondManager avec filtres serveur.' It clarifies the scope (client/prospect contacts) and distinguishes from sibling search tools (resources, companies, candidates), while the closing line differentiates it from boond_contacts_get by noting it returns a paginated summary list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a dedicated 'Cas d'usage courants' section with concrete recipes for common scenarios (my contacts, by company, by states/types, by period, by completeness, by name). It explicitly names the alternative for detail lookup: 'Utiliser boond_contacts_get ou les outils d'onglets pour le détail' and gives parameter patterns for each context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description focuses on additional behavioral nuances: server-side filtering, paginated return, sorting options, perimeter filter combination (OR by default, AND with narrowPerimeter), keyword prefix semantics, and projection behavior (unknown field names ignored). This meaningfully exceeds the annotations' safety-only information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is extremely information-dense and well-structured: a one-sentence purpose statement followed by bolded grouped bullet points for each logical use case, then sorting and return behavior. Every sentence adds actionable value for a complex 27-parameter search tool, and the formatting makes the content easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's high complexity (27 optional parameters, no required ones), the description covers the key filtering patterns, sort options, pagination, and explicitly points to detail tools for follow-up. The output schema exists, so not detailing the full return shape is acceptable. The description also mentions dictionary sources for many ID-based filters, making it nearly complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3, but the description adds substantial semantics on top: it explains how perimeterDynamic/perimeterManagers relate to user identity, gives concrete examples for state/type filters, and details keyword prefix conventions (CSOC, CCON, CAND, etc.). This goes well beyond the one-line schema descriptions and helps an agent choose and compose parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific statement: 'Recherche des opportunités commerciales dans BoondManager avec filtres serveur' — a search action on the opportunities resource with server-side filtering. It further distinguishes itself from detail-fetching tools by explicitly directing users to boond_opportunities_get for full detail, separating it clearly from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an extensive 'Cas d'usage courants' section that maps real-world intents (my opportunities, states/types, linked entities, business fields, positionings, date ranges) to specific filter parameters and examples. It also references dictionary tools for ID lookups and explicitly says to use boond_opportunities_get for detail, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent hints, the description reveals that filtering is done server-side and the result is a paginated list of projects. It also clarifies that this tool provides only summaries, not details, directing to complementary tools for richer data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with bullet points, starting with a one-line summary and then grouping filters by use case. It is detailed but not repetitive, with each bullet providing actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of optional parameters (21) and an output schema, the description covers the most common search scenarios, sorting options, and pagination, while leaving the rest to the schema. It also mentions the existence of other tools for detail, making it complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by giving scenario-based explanations, e.g., `period: "running"` plus `startDate`/`endDate` for projects running in 2026, and expands the keyword prefix list (including `PROD` and `MIS`) beyond the schema's set. Also clarifies that `perimeterDynamic: ["data"]` does not require knowing one's own ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Recherche des projets / missions dans BoondManager avec filtres serveur', clearly stating the verb (rechercher), resource (projets/missions), and server-side filtering. It distinguishes from sibling search tools by focusing on projects and explicitly redirects to boond_projects_get for detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides common usage patterns ('Cas d'usage courants') with concrete parameter examples, such as `perimeterDynamic: ["data"]` for one's own projects and `perimeterManagers: [<X_id>]` for a specific manager's projects. It also states 'Utiliser boond_projects_get ou les outils d'onglets pour le détail' to delineate when to use this search vs detail tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds significant behavioral context beyond annotations: server-side filtering, pagination behavior (page/pageSize/max values), sorting options, the default OR logic with #AND# override for tools, and the note that results are paginated and details require other tools. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but perfectly structured given the tool's complexity. It opens with a one-sentence summary, then organizes use cases into bullet points with bold labels, making it scannable and front-loaded. Every section serves a distinct purpose, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 34 parameters and zero required fields, the description is remarkably complete. It covers major filter categories (perimeters, states, skills, geography, availability), sorting, pagination, and points to additional tools for details and dictionary lookups. The output schema exists, so return value details are not needed. All crucial usage nuances are addressed, making this a thoroughly complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema description coverage is 100%, the tool description adds new meaning with concrete examples and combination rules (e.g., tools=['#AND#','12','34'] for AND logic, languages format 'langueId|niveauId', keywordsType behavior with fullName format). It clarifies relational semantics like perimeterDynamic as a shortcut for the current user, which goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource combination: 'Recherche des ressources (collaborateurs internes) dans BoondManager avec filtres serveur.' This clearly identifies the tool's purpose and distinguishes it from sibling tools like boond_resources_get (which fetches details by ID) and other search tools for candidates or contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance with explicit use cases and parameter combinations (e.g., perimeterDynamic for 'mes données', perimeterManagers for 'équipe d'une personne X'), references to supporting tools (boond_application_dictionary, boond_application_current_user), and a clear statement to use boond_resources_get for detailed views. It effectively tells when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations by detailing exact merge semantics per field (skills concatenation, key-based addition for tools/languages, fill-only-if-empty for scalar fields), replace semantics, and the behavior of omitted fields. This is especially valuable given the idempotentHint annotation, as it explains how idempotency is achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with clear section breaks for merge/replace modes, bullet points for fields, and a closing note on exclusions. Despite its length, every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 12-parameter schema, two modes, and no output schema, the description is exceptionally complete. It covers all field behaviors, mode differences, edge cases (omitted fields), and exclusions. An agent can confidently invoke this tool correctly without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage with descriptions, the description adds essential context by explaining how each parameter behaves under different modes (merge vs replace). This mode-dependent behavior is not inferable from the schema alone, making the description a critical complement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a resource's technical file (DT) and enumerates the specific field categories (competences, outils, langues, expertises, formations, diplomes, experience). It distinguishes itself by explicitly excluding professional references and pointing to dedicated reference tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it recommends 'merge' mode for automation, explains when to use 'replace' vs 'merge', and gives a direct alternative ('utiliser boond_resources_reference_{create|update|delete}') for reference management. It also clarifies that omitted fields are never reset, helping agents decide what to include.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![boondmanager-mcp-server MCP server](https://glama.ai/mcp/servers/fauguste/boondmanager-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/fauguste/boondmanager-mcp-server)

Score Badge

Copy to your README.md:

[![boondmanager-mcp-server MCP server](https://glama.ai/mcp/servers/fauguste/boondmanager-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/fauguste/boondmanager-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fauguste/boondmanager-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server