mcp-new-caledonia

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
Most tools have clearly distinct purposes, covering different domains like holidays, companies, mining, and census. A few pairs (e.g., nc_get_public_facilities vs. nc_search_facilities, nc_get_weather_stations vs. nc_get_rain_stations) could be confused, but their descriptions clarify the distinction. Overall, the risk of misselection is low.
Naming Consistency5/5
All tools follow a strict pattern of `nc_` prefix followed by a lowercase verb (get, search, is) and a snake_case noun phrase. There is no mixing of camelCase or inconsistent verb styles. This makes the tool names predictable and easy to navigate.
Tool Count3/5
With 29 tools, the count is above the typical heavy range (16-25), which could feel overwhelming. However, the server's scope is exceptionally broad, covering diverse public datasets from holidays to mining to transit. The count is justified by the wide domain, though it remains at the upper edge of appropriateness.
Completeness4/5
The tool surface provides strong coverage across the major data domains for New Caledonia, including companies, employment, environment, infrastructure, and demographics. Minor gaps exist, such as missing tools for education or tourism statistics, but the core workflows for the apparent purpose are well represented.
Average 3.3/5 across 29 of 29 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get statistics' — it does not state that the operation is read-only, what the response format looks like, whether parameters are required (they are all optional), what happens with no input, or any side effects. For a statistics retrieval tool, this is a significant lack of transparency, leaving the agent to guess the output structure and invocation behavior.
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 a single concise sentence that is front-loaded with the core action. It contains no wasted words, which is good, but it is too brief to be considered well-structured for a tool with multiple optional parameters and grouping semantics. It lacks the detail that could be conveyed in a few more sentences without becoming verbose. The conciseness is acceptable but not exemplary.
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?
There is no output schema and no annotations, so the description must provide sufficient context for an agent to call the tool correctly. It does not mention what the returned statistics represent, how the group_by options affect results, or the effect of omitting all parameters. While the schema explains parameters, the absence of response details and usage context leaves the tool incomplete for practical 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?
Schema coverage is 100%, so the schema already documents all three parameters (year, group_by, province) with descriptions and enums. The description adds only the vague 'by various criteria', which does not provide additional meaning beyond what the schema already offers. Baseline 3 is appropriate since the schema does the heavy lifting, and the description offers minimal extra 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 verb 'Get', resource 'statistics about job seekers', and location 'New Caledonia'. It distinguishes itself from siblings by topic — no other tool covers job seeker statistics, and it is clearly differentiated from population stats, vehicle stats, etc. The 'by various criteria' hints at filtering/grouping but the core 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 guidance on when to use this tool versus alternatives. It does not mention any sibling tools or conditions under which this tool should be preferred. The phrase 'by various criteria' is vague and does not explain the scenarios for using group_by or province filters. No exclusions or alternative recommendations are given.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states that the tool returns aggregate statistics. It does not reveal whether the operation is read-only (though a GET is implied by the name), what the response format looks like, whether pagination exists, or what 'statistics' means precisely (e.g., counts, averages, distributions). This lack of context is a significant gap for an unannotated tool.
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, efficient sentence that is front-loaded with the core purpose. It avoids unnecessary detail and is appropriately sized for a simple tool. However, it could briefly mention the response type or use case without becoming verbose, which would push it to a 5.
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 no output schema, so the description is not severely incomplete. However, it does not specify what kind of statistics are returned (e.g., count of companies per group) or any constraints on data range, and it omits any behavioral notes (auth, pagination). Given the lack of annotations, a more detailed description would help an agent understand the output, but the current description is minimally adequate for basic 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 schema already provides a description for the single parameter group_by ('How to group the statistics') and an enum with four values. Since schema coverage is 100%, the baseline is 3. The tool description adds no extra nuance about the parameter, such as clarifying that 'forme_juridique' refers to legal form or that 'ape' is an activity code, but it also does not need to because the enum values are reasonably self-explanatory and the schema provides adequate guidance.
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 ('Get'), a resource ('aggregate statistics about companies'), and a location ('New Caledonia'). It clearly conveys the tool's function, and it distinguishes itself from siblings like nc_get_company (individual company data) and nc_search_companies (search for specific companies). However, it does not explicitly name any sibling alternative, leaving the differentiation implicit.
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 others, nor does it mention any conditions or exclusions. It does not say 'use this to get counts or distributions of companies grouped by legal form' or indicate when to prefer a sibling like nc_get_companies_by_sector. An agent receives no context about the appropriate scenarios for choosing this tool.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'get', implying a read operation, but does not mention whether the output is a list, whether it supports pagination, data freshness, or any other behavioral traits. For a tool exposing a list of stations, the description is under-informative.
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 gets to the point without fluff. It is appropriately sized for the tool's simplicity, though it could be slightly more front-loaded with a hint of what the output contains. It earns a 4 for efficient use of 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 tool with one optional parameter and no output schema, the description is minimally sufficient but lacks details about the expected output format (e.g., list of station names, coordinates) or any special behavior. It is not misleading, but it could be more complete to help the agent set expectations. A 3 reflects adequate but not rich 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 schema description coverage is 100% since the only parameter 'commune' has a description 'Filter by commune'. The description adds no additional meaning beyond what the schema already provides. According to the rubric, with high coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'rain measurement (pluviometry) stations' with a geographic qualifier 'in New Caledonia'. This effectively conveys what the tool does. However, it does not explicitly distinguish it from sibling tools like nc_get_weather_stations, which could also relate to rainfall data, so it misses a clear 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 such as nc_get_weather_stations or nc_get_reef_stations. The description provides no context about typical use cases, prerequisites, or exclusions. An agent is left to infer usage from the tool name alone, which is insufficient for optimal 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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states the data source (census year) but does not disclose that this is a read-only operation, any limitations (e.g., missing data for certain provinces), or what the output looks like. For a 'get' tool with no annotations, more behavioral context is expected.
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, front-loaded with the principal action and resource. It is efficient with no filler. However, it is so minimal that it omits potentially useful details, but within the conciseness dimension, it is appropriately sized 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?
For a simple tool with one optional parameter and no output schema, the description provides the essential purpose and data source. However, it does not mention what statistics are returned (e.g., percentages, counts, breakup by mode), nor any caveats about data availability. With no annotations to supplement, the description is adequate but not 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 has 100% description coverage for the single optional parameter 'province', which is described as 'Filter by province' with an enum. The description adds no additional meaning beyond the schema. Baseline score of 3 applies because the schema already documents the parameter adequately.
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 verb ('Get') and resource ('statistics on transport modes used by the population'), and adds the data source (2019 census). It is unambiguous about the tool's purpose. It doesn't explicitly differentiate from sibling statistics tools (e.g., nc_get_population_stats, nc_get_vehicle_stats), but the resource is specific enough that an agent can infer the difference.
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 similar statistical tools among the siblings. There is no mention of alternatives, exclusions, or conditions. The description only states what the tool does, leaving the agent to guess when it is the right choice.
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?
No annotations are provided, so the description carries the full burden. It only states the purpose, not behavior such as read-only nature, pagination, error handling, or response format. The description offers no behavioral context beyond what a straightforward 'get' implies.
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 fluff or repetition. It front-loads the core purpose. However, it is so brief that it lacks structured context, but it earns points for 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?
For a tool with 3 optional parameters and no output schema, the description is minimal. It doesn't mention defaults, filtering semantics, or the nature of the results. An agent would have to rely on the schema alone, and the description offers no examples or additional context to ensure correct 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?
Schema description coverage is 100% (all three parameters have descriptions). The description adds no extra meaning beyond the schema, so it relies on the schema. The baseline for high coverage is 3, and the description contributes nothing additional.
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 verb 'Get' with a specific resource 'water catchment points for drinking water supply in New Caledonia'. This distinguishes it from most siblings that target other data types (weather, mining, facilities). However, it doesn't explicitly differentiate from other 'get' tools, but the resource is specific enough.
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 other data retrieval tools. There is no mention of use cases, filters, or alternatives. The agent must infer from the resource name alone, which is vague without 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Search', implying a read operation, but does not disclose any specifics like whether results are paginated, sorted, or limited in any way. It also doesn't mention any side effects or special behavior, leaving the agent with minimal insight into how the tool behaves.
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 a single short sentence with no fluff, but it is under-specified rather than concisely informative. It lacks key details (e.g., what the results look like) while being brief. It is not bloated, but its brevity comes at the cost of usefulness.
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?
There is no output schema, so the description should explain what the tool returns. It does not mention return format, whether it returns full job details, pagination behavior, or any sorting options. For a search tool with multiple filters, this is a significant gap, making the description incomplete for an agent to understand expected results.
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 four parameters are already documented in the schema. The description adds no additional meaning or context beyond what the schema provides. Per the baseline rule for high coverage, a score of 3 is appropriate because the schema already handles parameter semantics.
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 for job offers from the official New Caledonia employment portal. It uses a specific verb 'Search' and identifies the resource ('job offers'). Although it doesn't differentiate from siblings, there is no other job-search tool among them, so the core 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (official portal) but no explicit guidance on when to use this tool versus alternatives. Since no sibling tool targets job offers, a clear distinction is unnecessary, but the description still lacks any statement about when not to use it or what makes it the preferred choice for job-related queries.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Get data', implying a read operation, but gives no details on side effects, permissions, rate limits, pagination, or return format. For a tool with zero annotation coverage, this is a significant gap.
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 unnecessary words, making it appropriately sized for a simple data retrieval tool. It is front-loaded with the main action and resource, though it lacks supporting detail.
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 no output schema and no behavioral disclosure, the description should offer more context about what kind of data is returned, how the parameters relate, and any limitations. It leaves the agent to infer too much from the schema alone, making it incomplete for confident 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 descriptions for all three parameters (year, limit, employer_type), so the baseline is 3. The description adds no parameter-specific information, neither enhancing nor detracting from what the schema already states.
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 specifies a clear verb ('Get data') and a distinct resource ('New Caledonia and municipal civil servants'). It is unambiguous and easily distinguishable from sibling tools, which cover entirely different domains (holidays, companies, weather, etc.), so an agent can identify it without needing to open the schema.
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 any context about typical use cases, prerequisites, or when not to use it. Although no direct sibling tool covers civil servants, the description still does not state any usage context, leaving the agent to infer.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies a read operation, but does not state whether it is read-only, what side effects (if any) occur, or any limitations (e.g., only supports the 'nord' province). The description adds no transparency beyond the tool's name.
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 with zero filler. The core action ('Get GR information') is front-loaded, and the second sentence provides useful contextual background about NC's trails. Every word earns its place.
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 tool with one parameter and no output schema, the description is adequate but not complete. It tells the agent what the tool does but does not specify what 'trail information' includes (e.g., trail names, lengths, difficulty). Without an output schema, the agent would benefit from a note on the return format, but the description is not severely deficient.
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 single 'province' parameter is fully documented in the schema, including its enum, default, and description. The description adds no additional parameter meaning or syntax details beyond what the schema already provides. 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 states a clear verb ('Get') and resource ('GR hiking trail information'), and adds context that NC has two famous trails. It uniquely identifies this tool among siblings (no other trail-related tools exist), but does not specify what information is returned (e.g., names, distances), so it stops short of 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 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. While there are no sibling tools for trails, the description does not mention any exclusions or selection criteria. An agent must infer from the name that it is the trail-info tool; no usage context is given.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'get' without revealing response format, pagination behavior, data source, or any side effects. For a read operation this is minimal, but the absence of any performance or output details leaves the agent underinformed.
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, efficient sentence with no wasted words, front-loading the core purpose. It is appropriately concise, though it lacks any structural segmentation (e.g., sections or bullets) that could enhance readability for complex tools; for this simple tool, that is acceptable.
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 too sparse for a tool with 3 optional parameters and no output schema. It does not explain what fields or format the returned data will have, how the year and limit interact, or any caveats about data availability. An agent calling this tool would be uncertain about the response structure and how to process the results.
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 each parameter. The description's mention of 'nickel, ferronickel' duplicates the product_type examples in the schema. It adds no substantive meaning beyond the schema, hence 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 clearly states the verb (get), resource (metallurgical production data), and geographic scope (New Caledonia), with examples (nickel, ferronickel). It is specific and distinguishable from sibling tools, none of which directly overlap in function.
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, nor any exclusions or prerequisites. The agent must infer usage from the name and description alone, lacking direction on scenarios that might favor another tool.
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?
No annotations are provided, so the description must carry the behavioral disclosure burden. The single sentence only states the basic read operation and gives no detail about default behavior, grouping, filtering, or return format. This is minimal transparency for a tool that offers optional parameters.
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 sentence with no filler, and it front-loads the core purpose and scope. It is appropriately concise, though it contains no additional structural elements like parameter or behavior highlights.
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 no annotations and no output schema, the description needs to provide more context about what the returned statistics look like and how parameters alter the result. The current text only states the data source and general subject, leaving an agent uncertain about response shape and tool behavior.
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 parameters having clear descriptions in the schema: 'How to group results' and 'Filter by province'. The description adds no additional parameter context, so the baseline score 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 a specific action ('Get') and resource ('population statistics from the 2019 census of New Caledonia'). It is distinct enough to know its subject matter, though it does not explicitly contrast it with sibling statistics tools like 'nc_get_job_seeker_stats' or 'nc_get_vehicle_stats'.
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: call this when you need New Caledonia 2019 census population statistics. However, it does not provide any when-to-use versus alternatives guidance, nor does it mention the grouping/filtering options that could direct an agent to this tool over related ones.
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?
No annotations are provided, so the description must disclose behavioral traits on its own. It only says 'Get' which implies a read operation, but it does not specify whether the tool returns a list, supports pagination, or requires any authentication. It also does not describe any response format or potential errors, leaving the agent with little information about the tool's 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, efficient sentence that leads with the verb and object, immediately conveying the tool's core purpose. There is no fluff or redundant information. It earns a high score for being concise and front-loaded.
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?
For a tool with no annotations and no output schema, the description is too sparse to fully equip an agent to decide when to invoke it. It lacks usage guidelines, behavioral details, and any mention of the search alternative (nc_search_facilities). Given the tool has three optional parameters and a specific geographic scope, the description should do more to contextualize its role among the many sibling tools.
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 complete descriptions for all three parameters: type (enum with detailed values), limit (max results), and commune (filter by commune). The description adds the geographic context 'Greater Nouméa' which is not in the schema, and gives examples of facility types that align with the enum. However, since the schema already documents the parameters well, the added value is modest, but the geographic scope nudges it to a 4.
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 (Get), the resource (public facilities), and the geographic scope (Greater Nouméa), and gives examples of categories (schools, sports, health, transport) that align with the enum in the schema. It does not explicitly distinguish from the sibling nc_search_facilities, which could be a general search alternative, so it falls short of 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 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 nc_search_facilities or other facility-related tools. It does not mention any exclusions or preferred contexts. This forces 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Search' which implies a read-only operation, but does not explicitly state that it has no side effects, or disclose pagination, sorting, or result format beyond the limit parameter. The behavioral profile is underspecified for a tool with no annotation safety 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?
A single, efficient sentence that states the action and scope with no extraneous words. It is appropriately front-loaded and easily scannable.
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 two-parameter search, the description is adequate but incomplete given the sibling ecosystem. It does not mention when to prefer this over nc_get_public_facilities, nor does it describe output shape. The schema covers parameters but behavioral and selection context is missing.
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 both parameters ('Search term' and 'Max results'). The description adds no additional semantic nuance beyond what the schema already documents, 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 a specific verb ('Search') and resource ('public facilities by name in Greater Nouméa'). It distinguishes from the sibling nc_get_public_facilities by implying search rather than retrieval of all facilities, though it does not explicitly name that alternative.
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 vs. alternatives. Given the sibling nc_get_public_facilities, the description does not clarify whether to use search for name-based filtering or get for full listings. An agent must infer the distinction from the verb alone.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and identifier, with no information about response format, error handling, authorization requirements, or other side effects. This is a significant gap for a tool that returns 'detailed 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?
The description is a single, concise sentence with no redundancy. The purpose and identifier are front-loaded, making it immediately parseable.
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 no output schema, no annotations, and a tool that promises 'detailed information', the description provides minimal guidance on what the response will contain or how to handle edge cases (e.g., invalid or missing RIDET). It is one of many similar get/stat tools among siblings, and the description does not sufficiently differentiate or elaborate.
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 documents the ridet parameter with a pattern and explanation. The tool description adds nothing beyond the schema's own parameter description, so it does not enhance semantic understanding.
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 clear verb ('get') and resource ('detailed information about a specific company') and identifies the unique identifier (RIDET number). It distinguishes from siblings that search or aggregate, though 'detailed information' is somewhat vague about what fields are included.
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 phrase 'using its RIDET number' implies this tool is for when you already have the RIDET identifier, contrasting with search tools like nc_search_companies. However, it does not explicitly state when not to use this tool or mention any alternatives, leaving some inference to the agent.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but does not explicitly state that it is safe or requires permissions. It also does not describe output format, pagination, or any side effects. The description does not contradict any annotations (since there are none), but it fails to provide meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences. However, the second sentence 'NC is the world #1 ferronickel producer' is tangential to the tool's function and adds no operational value. The core information is front-loaded, but the extra sentence could be omitted without loss. Overall, it is efficient but not maximally focused.
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 query tool with three optional parameters and no output schema, the description is minimally adequate. It does not explain return values or how to interpret results, but since the schema covers parameters and the tool is straightforward, the description is not severely incomplete. Still, it lacks context about what the data represents beyond the parenthetical examples.
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 all three parameters with descriptions and enum values, achieving 100% coverage. The description adds no additional meaning about the parameters—it just names the resource. Since the schema covers everything, 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 the tool's purpose: 'Get mining titles (concessions, research permits) in New Caledonia.' It specifies the resource (mining titles) and geographic scope, which distinguishes it from sibling tools that cover holidays, companies, or weather. The verb 'Get' and the resource are specific 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 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 any prerequisites, filtering conditions, or when a different tool might be more appropriate. The agent must infer usage solely from the tool name and description, which is minimal.
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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action without describing return format, pagination behavior, data granularity, or any access or rate constraints. For a simple getter it is minimal but still lacks transparency about what the agent will actually receive.
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 with no superfluous words. It front-loads the core action 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.
Completeness2/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 should at least indicate what the response contains (e.g., coordinates, site names, time series). It does not. The tool has only two optional parameters, so complexity is low, but the absence of any usage or result details leaves it incomplete for practical calling.
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 100% coverage for both parameters ('Max results' and 'Filter by commune'), so the baseline is 3. The description adds no extra meaning beyond the schema; it does not clarify the format of 'commune' or how 'limit' interacts with paging.
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 ('Get'), the resource ('piezometer locations'), and the purpose ('for groundwater level monitoring'). It is specific enough to distinguish from sibling tools like nc_get_rain_stations or nc_get_water_catchments, each of which targets a different monitoring type.
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 offers no guidance on when to use this tool versus alternatives, nor does it mention any conditions, prerequisites, or filtering strategies. An agent is left to infer that this is the only tool for piezometer data, but there is no explicit usage 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?
No annotations are provided, so the description carries the full burden. It implies a read-only retrieval operation but discloses no behavioral details such as pagination behavior, response format, data freshness, or any access considerations. The UNESCO heritage sentence adds context but not behavioral transparency.
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 core purpose. The second sentence adds background context but is not strictly necessary; however, it is brief and does not significantly dilute the message.
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 listing tool with one optional parameter, the description is minimally viable. It explains what the tool retrieves, but with no output schema and no annotations, it leaves gaps about what station data is returned and how results are ordered or aggregated.
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 only parameter, 'limit', is already documented as 'Max results' in the schema. The description adds no parameter-specific meaning, but the schema handles it adequately, 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 names a specific verb ('Get'), a specific resource ('coral reef observation network (RORC) monitoring stations'), and expands the acronym. This clearly distinguishes it from sibling station-related tools like weather and rain stations.
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 explicit guidance on when to use this tool versus alternatives. It does not identify sibling tools, mention exclusions, or state conditions that would make this tool the right choice.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the high-level purpose without mentioning that all parameters are optional, that results are aggregated statistics, or that it is a read-only operation. The absence of any behavioral context beyond the basic statement is a significant gap.
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 front-loads the core action and subject. Every word is necessary, and there is no verbosity or redundancy. This is an ideal length and structure for a straightforward tool.
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 three optional parameters and no output schema, the description is insufficiently complete. It does not specify what the statistics represent (e.g., counts, percentages, breakdowns), what the output format will be, or how to interpret the result. In the absence of annotations and an output schema, the description should provide more operational 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%, with each parameter having a meaningful description (e.g., 'Registration year', 'How to group results'). The tool description adds no additional parameter context or examples, but the baseline for full coverage is met. It does not go beyond the schema, so a 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 statistics about registered vehicles in New Caledonia, specifying both the verb (get) and the resource (vehicle statistics). This uniquely distinguishes it from sibling tools like population or company statistics, which are clearly different domains.
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. With many sibling statistics tools (e.g., population, demographics, company statistics), there is no differentiation of use cases or explicit exclusions. An agent would have to infer applicability solely from the resource name.
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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read-only operation, but does not specify what the tool returns (e.g., a list of stations, fields, whether the commune filter is applied, any pagination). It omits any side effects or limitations, which is inadequate for a data retrieval tool.
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 directly conveys the core purpose. It is front-loaded with the action and resource, contains no extraneous words, and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks essential context beyond the purpose. It does not explain the expected output, how the commune filter works in practice, or how it differs from similar station tools. With no annotations and no output schema, the description should provide more guidance to the agent for correct invocation, but it leaves these points unexplained.
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 documents the single 'commune' parameter with a description ('Filter by commune'), and coverage is 100%. The tool description adds no further meaning about the parameter, such as format, default behavior, or accepted values. Since schema coverage is high, the baseline of 3 applies, and the description does not improve upon 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 action ('Get'), the specific resource ('Météo France weather stations'), and the geographic scope ('in New Caledonia'). This distinguishes it from sibling tools like rain stations, reef stations, and others by naming the provider and type, 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 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 such as nc_get_rain_stations or nc_get_reef_stations. The description does not mention any conditions, exclusions, or comparisons to siblings, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without any mention of side effects, read-only guarantees, auth requirements, rate limits, or output characteristics. The tool appears to be a read operation, but that is only implicit and not explicitly 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, front-loaded sentence with no fluff. It conveys the essential purpose efficiently. The structure is clear and wastes no 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 tool with one optional parameter and no output schema, the description is minimally adequate. It states the data source and what is returned, but does not describe the structure of the age groups or any variations. Given the simplicity, this is sufficient but leaves room for improvement in specifying output details.
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%: the only parameter 'province' is described and has an enum. The description adds no extra meaning about the parameter beyond what the schema already provides. According to the calibration, a baseline of 3 is appropriate when schema coverage is high and description does not compensate 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 clearly states the action (Get), the resource (demographic breakdown by age groups), and the data source (2019 census). It is specific enough to distinguish from sibling tools like nc_get_population_stats, which covers population stats broadly but not specifically age-group breakdowns. The verb 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 guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or relationships to sibling tools. An agent must infer usage solely from the name and schema, without any contextual hints about appropriate 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?
No annotations are provided, so the description alone must carry behavioral disclosure. It merely states the retrieval action without addressing return format, pagination, rate limits, authorization, or any side effects. The absence of such details makes it insufficient for an agent to confidently predict 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, focused sentence with no filler. The key differentiator ('Nickel Fund') is front-loaded, making it immediately scannable and efficient for an agent 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?
Given there is no output schema and no annotations, the description leaves the agent without details on response structure or additional constraints. While the tool appears simple, the lack of any hint about what fields are returned or how results are ordered is a minor gap for a retrieval tool. It is adequate but not comprehensive.
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?
Both parameters (limit, commune) are fully described in the schema with 'Max results' and 'Filter by commune'. The description adds no additional meaning beyond these, and since schema coverage is 100%, 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 specifies a concrete action ('Get') and a precise resource ('sites managed by the Nickel Fund for environmental rehabilitation of former mining areas'). This clearly distinguishes it from sibling tools like nc_get_dry_forest_sites or nc_get_mining_titles, leaving no ambiguity about what this tool retrieves.
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, and no context for when the Nickel Fund scope applies. The description simply states the action, leaving the agent to infer usage. No sibling comparisons or conditions are 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?
With no annotations, the description carries the behavioral disclosure burden. It usefully states that only active companies are returned and explains RIDET's role, but it does not describe result shape, pagination, matching behavior, or any operational caveats. This is a non-mutating lookup, so the omission is moderate rather than severe.
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, each earning its place: the first states the operation and scope, the second clarifies the registry. No 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?
For a simple search with fully described parameters this is largely adequate, but there is no output schema and the description does not say what the search returns or how results are ordered or paginated. It also omits usage boundaries relative to sibling tools, leaving some uncertainty for an agent deciding between 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%, so all four parameters already have descriptions (query, limit, sector, commune). The tool description adds registry context but no extra parameter-level meaning, so 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 names a specific action ('Search'), a target ('active companies'), and a specific registry ('New Caledonia RIDET'), with a helpful France SIRET analogy. It is clear what the tool does, though it does not explicitly contrast it with sibling tools like nc_get_company or nc_get_companies_by_sector.
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 prefer this search over nc_get_company or nc_get_companies_by_sector, or when the sector/commune filters should be used instead. The only inferred context is the word 'Search'; no exclusions or alternatives are named.
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?
No annotations are present, so the description carries the full burden of disclosing behavior. It accurately communicates a read-only retrieval operation returning all public holidays for a year. However, it does not mention output format, handling of empty results, or any error behavior, which is acceptable for a simple getter but not deeply transparent.
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 with no filler. The first sentence front-loads the action and resource, and the second sentence provides meaningful regional context that helps justify why this tool exists. Every word contributes value.
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 tool, the description plus schema provides enough to invoke it correctly. However, the presence of sibling tools like nc_is_public_holiday and nc_get_upcoming_holidays means a brief note distinguishing when to use this tool would improve selection accuracy. The lack of an output schema also leaves the return shape unspecified.
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 only parameter, year, including type, range, and default. The description only restates that the tool works 'for a specific year' and adds no additional semantic detail, so it does not go 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 uses a specific verb and resource: 'Get all public holidays in New Caledonia for a specific year.' It clearly defines the scope and adds useful geographic context by noting New Caledonia differs from mainland France. It does not explicitly name sibling tools like nc_is_public_holiday or nc_get_upcoming_holidays, so differentiation from them is only implicit.
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: use this when you need the full set of public holidays for a specific year in New Caledonia. However, the description does not provide explicit when-to-use or when-not-to-use guidance relative to closely related sibling tools such as nc_is_public_holiday or nc_get_upcoming_holidays.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only explains the score meaning but does not mention any side effects, read-only nature, data volume, or other behavioral traits. The 'get' verb implies a safe read, but this is not explicitly stated.
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, concise sentence that front-loads the action and resource, and includes a meaningful clarification about the score's interpretation. 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 tool with two optional filters and no output schema, the description is largely complete. It explains the meaning of the index, which is valuable for correct interpretation. The schema already indicates optionality by not marking parameters as required, so no further clarification is 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 already provides descriptions for both parameters ('Filter by commune name' and 'Filter by province') with 100% coverage, so the description does not need to add param details. It does not explain how filters combine or any value formatting, but the baseline for high schema coverage is 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's function: retrieving a digital fragility index for communes in New Caledonia, with an explicit interpretation of the score. It distinguishes itself from sibling tools, which focus on completely unrelated domains.
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 the tool would be used (when digital fragility data is needed) but provides no explicit guidance on when to prefer it over alternatives or exclusions. No sibling tools perform a similar function, so the context is inferred rather than stated.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not specify whether the operation is read-only (likely but not stated), what the response format looks like, how pagination works (though limit parameter exists), or any potential side effects or data freshness. It also does not clarify if special schemes are mutually exclusive or inclusive, leaving ambiguity.
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, well-constructed sentence that effectively communicates the core purpose. It is concise and front-loads the primary function. It could arguably be split into two sentences to improve readability, but it remains appropriately sized 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?
The tool has only two optional parameters and no output schema, so the description needs to cover what the response contains and any behavioral nuances. It does not describe the structure of returned company data, pagination beyond the limit parameter, or error conditions. The special scheme clarification is helpful, but overall the description is minimal for a data-retrieval tool and leaves some gaps.
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 documents both parameters with 100% coverage, so the baseline is 3. However, the description adds semantic value beyond the schema by explicitly naming the special nickel and civil unrest schemes, which maps to the enum values 'nickel' and 'exactions'. This clarifies the meaning of the type parameter and enriches the agent's understanding beyond the bare enum 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 verb 'Get' and the resource 'companies on partial unemployment schemes in New Caledonia'. It explicitly mentions the special nickel and civil unrest schemes, distinguishing it from other nc_* tools like nc_search_companies or nc_get_company_statistics, which cover different data domains.
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 partial unemployment data, but does not explicitly state when to use it over alternatives or when not to use it. There is no mention of prerequisites, context, or conditions that would select this tool instead of others. The guidance is implied through the topic, but not 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?
No annotations are provided, so the description carries the full burden. It states what the tool does but reveals no additional behavioral traits: no mention of return format (e.g., list of date/name pairs), no mention of timezone handling, no note on data source freshness, and no explicit statement that this is a read-only operation. The description is minimal beyond the action itself.
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, information-dense sentence that front-loads the core purpose. No wasted words, and it is appropriately brief for a simple getter 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 the tool's simplicity (one optional parameter, no output schema, no nested objects), the description provides enough context for an agent to understand its function. It could mention what the response contains (e.g., holiday names and dates) but that is a minor gap. The description is nearly complete; a 4 reflects the slight lack of return-spec 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?
The schema covers the single 'limit' parameter with a full description including default, minimum, and maximum values. Since schema_description_coverage is 100%, the description does not need to add parameter details. It adds no extra meaning beyond the schema, 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 clearly states the action ('Get'), the resource ('next upcoming public holidays'), and the scope ('in New Caledonia from today'). It distinguishes itself from sibling tools like nc_get_public_holidays (which likely returns all holidays) and nc_is_public_holiday (which checks a specific date) by specifying the temporal focus.
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 upcoming holidays but does not explicitly guide when to choose this tool over alternatives. It lacks mention of sibling tools or conditions like 'use for future dates only' or 'if you need a specific date, use nc_is_public_holiday'. The context is clear but not framed as usage guidelines.
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?
No annotations are provided, so the description carries the burden. It states 'Get all companies' which may mislead an agent into expecting unlimited results, whereas the schema includes a default limit of 50. It also does not mention the commune filter or any pagination behavior. While the description is honest about the general action, it omits notable behavioral nuances.
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 primary action and scope. It contains no filler and is exactly as concise as needed.
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 a simple retrieval tool, but the phrase 'all companies' conflicts with the limit parameter, potentially causing incorrect expectations. It also does not mention the commune filter, though that is covered by the schema. Given the low complexity, it is mostly complete but has a notable gap regarding the limit behavior.
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 three parameters. The description adds only minor context for sector_code (identifying it as APE/NAF) and does not clarify limit or commune beyond what the schema provides. This meets the baseline but 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 clearly states the verb (Get) and resource (all companies in a specific activity sector), and distinguishes it from siblings like nc_search_companies and nc_get_company by focusing on the sector filter. It is specific 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 for retrieving companies by sector but does not explicitly mention when to prefer this over nc_search_companies or other tools, nor does it provide exclusions. The context is clear enough for a simple use case, but there is no explicit guidance on 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?
No annotations are provided, so the description carries full burden. It only states what the tool does but does not disclose the return format (e.g., boolean true/false), any edge cases, or error behavior. Without output schema, this is a significant gap for an agent to correctly interpret the result.
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 wasted words. It is front-loaded with the core action and subject, making it easy to scan.
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), but the description fails to specify the return value or behavior, which is essential given there is no output schema. The agent cannot know if it returns a boolean, holiday details, or something else, so completeness is only partially satisfied.
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 parameter 'date' already has a clear description in the schema ('Date to check in YYYY-MM-DD format'). The tool description adds no additional semantic information beyond what the schema provides, so a 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 a precise action ('Check') and a specific resource ('a specific date is a public holiday in New Caledonia'). It clearly distinguishes this from sibling tools like nc_get_public_holidays (which likely returns lists) by focusing on a single date.
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 checking one date, which provides clear context. However, it does not explicitly contrast with alternative sibling tools (e.g., nc_get_public_holidays for a range), so it lacks explicit when-not guidance, but the context is still 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?
There are no annotations, so the description carries the full burden. It states 'Get', which implies a read operation, but it doesn't disclose any behavioral details like pagination, sorting, or whether the results are filtered by default. The description adds context about the ecosystem but not about tool behavior, leaving the agent to infer from the schema parameters. This is minimal but not misleading, so a 3.
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, front-loaded with the action and resource. The second sentence provides contextual value about the ecosystem but doesn't bloat. 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?
The tool has no output schema, but the description names the resource clearly enough. It doesn't describe return format or potential response structure, but for a simple 'get list' tool, the name and description suffice. Given the simplicity and no annotations, the description covers the essential context. A 4, as it doesn't overreach but leaves minor room for more detail (e.g., typical response size).
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 describes all three parameters (limit, commune, fire_priority) with descriptions, so coverage is 100%. The description adds nothing about parameter meaning beyond the schema, which meets the baseline of 3. No additional semantics are needed.
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?
Description states a specific verb ('Get'), a specific resource ('dry forest conservation sites'), and a specific location ('New Caledonia'), which clearly differentiates it from all sibling tools. Even without the schema, an agent knows exactly what this tool returns.
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 no guidance on when to use this tool versus alternatives or any exclusions. However, among the listed sibling tools, none are similar (no other conservation or dry forest tool), so the lack of explicit routing guidance is a minor gap. Still, the dimension asks for explicit guidance, so it scores 3.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get information' implies a read-only operation, but the description doesn't elaborate on any special behaviors such as response format, potential rate limits, or authentication needs. For a simple no-parameter GET, 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, well-structured sentence that immediately states the verb and resource. It is concise, front-loaded, and contains no filler—every word earns its place.
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 low complexity (no params, no output schema), the description is mostly sufficient, but it uses the vague term 'information' without specifying what kind of data is returned (e.g., schedules, routes, stations). An agent might wonder what exactly will be retrieved, though the purpose is clear enough for a simple info 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?
The tool has zero parameters and the input schema is an empty object. According to the rubric, the baseline for 0 parameters is 4. The description doesn't need to explain any parameters, and it correctly focuses on the tool's purpose.
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 specific verb 'Get information' and the precise resource 'Tanéo public transport network' with a defined service area. It is unambiguous and distinguishes itself from siblings like nc_get_transport_modes, which might cover broader transport topics.
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 is for information about the Tanéo network in Greater Nouméa. It doesn't explicitly contrast with alternatives, but the specificity of the resource makes the usage scenario obvious. An agent can infer when to use this tool without confusion.
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:

[![mcp-new-caledonia MCP server](https://glama.ai/mcp/servers/lacausecrypto/mcp-new-caledonia/badges/card.svg)](https://glama.ai/mcp/servers/lacausecrypto/mcp-new-caledonia)

Score Badge

Copy to your README.md:

[![mcp-new-caledonia MCP server](https://glama.ai/mcp/servers/lacausecrypto/mcp-new-caledonia/badges/score.svg)](https://glama.ai/mcp/servers/lacausecrypto/mcp-new-caledonia)

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/lacausecrypto/mcp-new-caledonia'

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