Trimble Connect MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Many tools have overlapping purposes, e.g., multiple tools for creating BCF topics (tc_bcf_create_topic, tc_bcf_create_app, and tc_bcf's topic_create). Similar confusion exists for todos, views, and activities. The agent may struggle to select the correct tool among redundant options.
Naming Consistency2/5
Naming is inconsistent: some tools use no tc_ prefix (e.g., search_trimble_connect_docs), while most use tc_. Some tools follow verb_noun pattern (tc_list_projects), but many are noun-only with action parameters (tc_files, tc_bcf). Mixing 'tc_' and 'tc_bcf_' prefixes and appending '_app' for UI tools adds further inconsistency.
Tool Count2/5
53 tools is excessive for an MCP server. While the domain is broad, many tools are thin wrappers over API endpoints. This number overwhelms agents and makes tool selection inefficient. A more consolidated surface (e.g., 15-25 tools) would be appropriate.
Completeness3/5
The tool set covers many aspects of Trimble Connect (projects, files, BCF, todos, etc.), but there are redundancies and gaps. For example, model-specific operations beyond clash detection are missing, and some CRUD operations are scattered across multiple tools. Overall coverage is moderate but not polished.
Average 3.7/5 across 53 of 53 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 for behavioral disclosure. It only states the action without mentioning if the tool is read-only, requires authentication, has rate limits, or what the output size or format is.
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?
A single sentence with no wasted words. Efficient, but could include more detail without being verbose, such as clarifying the output format or scope.
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 simple schema and lack of output schema, the description is minimally complete. However, considering numerous sibling tools, it could better differentiate by mentioning the output is a comprehensive reference (e.g., list of endpoints) or that it covers a category.
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 baseline is 3. The description does not add any additional meaning beyond the schema; it does not explain the enum values or the 'section' parameter. No value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete reference documentation for a specific API category. The verb 'get' and resource 'reference documentation' are specific. However, it does not differentiate from siblings like 'search_trimble_connect_docs' or 'list_available_docs' beyond the scope of 'complete' and 'specific category'.
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 context on prerequisites, when not to use, or which sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It only says 'Get a comprehensive guide' without mentioning output format, authentication needs, or any side effects. As a read operation, more clarity on what a 'guide' entails is needed.
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. It is front-loaded and efficient, though it sacrifices detail for brevity. Every word earns its place, but it could provide more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the single parameter, the description should explain what the guide contains (format, depth). It only says 'comprehensive', which is vague. The tool's purpose is reasonably clear but insufficient for the agent to understand the response shape.
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%, baseline is 3. The description adds no extra meaning beyond the schema's 'Viewer 3D API topic'. The enum values are listed but not explained, so the parameter semantics are not enhanced.
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 'comprehensive guide for a specific Viewer 3D API topic'. It distinguishes from siblings like get_api_reference by specifying the context (Viewer 3D API), but does not differentiate from get_extension_starter or search_trimble_connect_docs.
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 like get_api_reference or search_trimble_connect_docs. It does not specify prerequisites or context 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?
No annotations are provided, so the description must carry full burden. It lists actions but does not disclose behavioral traits such as side effects, required permissions, rate limits, or whether operations are destructive. For instance, 'topic_delete' is listed without any warning about irreversible deletion. The description is purely functional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long (over 50 lines) with a massive bulleted list of 44 actions. While it front-loads BCF version and path placeholder info, the bulk is a wall of text that is hard to scan. It would benefit from grouping by resource or using tables. Not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 44 actions, no output schema), the description lists all actions and their parameters, which is complete in terms of action coverage. However, it lacks explanation of return values, error handling, or authentication. The absence of output schema is not compensated by description details on response structure. Adequate but with clear 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how path placeholders ({id}, {subId}, etc.) are filled from parameters and by providing endpoint details (HTTP method, path, and body requirements for many actions). For example, 'topic_create' notes body fields like title, description, topic_type, etc. This goes beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the Trimble Connect BCF/Topic API and lists over 40 actions covering topics, comments, viewpoints, etc. It specifies verb+resource for each action (e.g., 'topics_list: GET /projects/{projectId}/topics'). However, it does not differentiate from sibling tools like tc_bcf_list_topics or tc_bcf_create_topic, which appear to be more specific wrappers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. Given sibling tools like tc_bcf_list_topics and tc_bcf_create_topic, there is no explanation of trade-offs or when to prefer the generic tc_bcf over the more specific ones. No when-not-to-use or alternative suggestions.
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 full burden. It implies the download URL is always included, but the parameter includeDownloadUrl (default false) controls this, creating potential confusion. No mention of permissions, error behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded with the core action and includes key outputs (versions and download URL), making it efficient.
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 parameters, no output schema, and no annotations, the description is insufficient. It lacks details on return format, error cases, rate limits, or prerequisites, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description adds no extra semantic value beyond the schema, but baseline is acceptable given the schema's completeness.
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's purpose: retrieving details of a specific file, including versions and download URL. It distinguishes from sibling tools like tc_search_files and tc_get_folder_contents by specifying it's for a single file, but does not explicitly differentiate.
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. Sibling tools like tc_search_files and tc_get_folder_contents exist, but the description does not mention scenarios where this tool is preferred or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral details such as what 'recent' means, pagination behavior, required permissions, or whether the operation is read-only. With no annotations, the burden is entirely on the description, which fails to provide adequate 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 a single, concise sentence with no extraneous words. It is front-loaded with the key action and resource.
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 that there is no output schema and no annotations, the description is underinformative. It lacks details on output format, pagination, the definition of 'recent', and any prerequisites or side effects.
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 parameters. The description adds no additional parameter information, thus scoring the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent activities in a project, adding the context of 'audit trail'. It is specific enough to differentiate from many sibling tools that focus on other entities like files, todos, or views.
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 over alternatives, such as tc_activities or other listing tools. Siblings are numerous but no distinctions are made.
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, description must disclose behavioral traits. It only states basic function; no mention of permissions, pagination, or output format.
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?
Single, front-loaded sentence that efficiently communicates purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal for a simple list tool; no annotations and missing details like return structure or constraints. Lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description adds no extra meaning beyond schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'members of a project'. It distinguishes from sibling tools like tc_list_projects and tc_get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., tc_get_project for single project details, or tc_list_todos for different resources). No exclusions or context provided.
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 must fully disclose behavioral traits. It only states the function without mentioning safety, permissions, pagination, or empty set behavior. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. Concisely communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, a list tool should describe return format or pagination. The description is too sparse for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional semantic value beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource '3D views' with per-project scope. However, it does not explicitly distinguish from sibling tools like 'tc_views' or 'tc_views2d', which could be ambiguous.
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 prerequisites or when-not-to-use scenarios. The description lacks usage context entirely.
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 exist, so the description must disclose behavioral traits. It only states 'search' without mentioning important details like pagination, sorting, rate limits, or what data is returned. This is insufficient for safe invocation.
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 extremely concise with one sentence, front-loading the core action. However, it is so brief that it sacrifices completeness; still, no unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required), no output schema, and no annotations, the description is too minimal. It does not explain search behavior (e.g., filename vs content search), limitations, or return structure, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the description adds no extra meaning. Baseline 3 is appropriate as the schema already explains parameter roles 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 tool searches for files in a project, using a specific verb and resource. However, it doesn't differentiate from related siblings like 'tc_files' or 'tc_get_folder_contents', which might also involve searching or listing files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no exclusions or context for appropriate use cases, leaving the agent without decision-making support.
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, and the description only says 'update'. It does not disclose behavioral traits such as whether partial updates are allowed, idempotency, authorization requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at three words, but effectively communicates the core action. It is front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient. It does not explain behavior such as required fields, error conditions, or the result of the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning beyond what is already provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates an existing todo/note, which is a clear verb+resource. It distinguishes from create tools like tc_create_todo, but does not specify which fields are updatable beyond what the schema provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus creating a new todo or other operations. No prerequisites or exclusions are mentioned.
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, and the description does not disclose any behavioral traits such as side effects, authentication requirements, rate limits, or what happens on failure. For a creation tool, more context is needed.
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, but it omits important usage and behavioral information. It is minimal but not optimally structured for an agent.
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 or annotations, the description should provide more context about the return value (e.g., project ID) or prerequisites. It is incomplete for a tool with 3 parameters and no structured guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so the description does not need to add much. However, it adds no additional meaning beyond the schema, such as clarifying the enum values or providing examples. 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 (create) and the resource (a new project) in Trimble Connect. It distinguishes from sibling tools like tc_list_projects or tc_get_project which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, permissions, or context provided. The description is too brief to inform an agent about appropriate usage.
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 bear the full burden. It only states the general purpose without disclosing behavioral traits like whether the operation is idempotent, authentication needs, or effects on existing data. For a mutation tool, this is insufficient.
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 of 10 words, which is efficient and front-loaded. However, it sacrifices completeness for brevity. It earns a 4 because it is not verbose, but it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema or annotations, the description is too minimal. It fails to explain return values, error states, or the broader context of the creation operation, leaving the agent without sufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the schema already documents parameter meaning. The description adds no additional semantic value beyond what is in the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('BCF topic'), and the context ('in a project'), with the parenthetical '(issue)' clarifying the BCF term. This is specific and distinguishes it from sibling tools like 'tc_bcf_list_topics' which is for listing.
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 'tc_bcf_list_topics' or other creation tools. It does not mention prerequisites, required permissions, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states a listing operation with no details on side effects, permissions, pagination, or what the response contains. The agent cannot infer important behavioral traits like read-only nature or rate limits.
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, front-loaded sentence that efficiently communicates the core purpose. It is concise but could be enhanced with minor details without increasing bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being simple, the description omits essential context: no output specification (no output schema), no mention of prerequisites (project must exist), and no indication of pagination or limits. The agent lacks complete information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both region and projectId have descriptions). The tool description adds no additional parameter information beyond the schema. Baseline score of 3 is appropriate as per guidelines.
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 ('List'), the resource ('BCF topics'), and the context ('in a project'), with the parenthetical '(issues)' providing further clarification. This distinguishes the tool from sibling tools like tc_bcf_create_topic or tc_list_todos.
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 (e.g., tc_list_todos or search tools) or any prerequisites (e.g., valid projectId). No when-not or explicit conditions are mentioned.
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 full burden for behavioral traits. It only says 'Get details,' omitting whether the operation is idempotent, requires authentication, handles errors, or has rate limits. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It front-loads the purpose efficiently. Every word contributes meaning, and there is no unnecessary repetition. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema, the description is basic. It says 'Get details' but doesn't indicate what is returned (e.g., project object fields). For a simple get operation, it's adequate but not thorough. Could be improved by noting return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for region (enum with meanings) and projectId (string). The description adds no extra meaning beyond the schema. Baseline 3 is appropriate since schema already documents parameters well.
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 'Get details of a specific project,' which is a specific verb+resource combo. It implicitly distinguishes from sibling tools like tc_list_projects (list all) and tc_create_project (create). However, it does not explicitly differentiate, and could be more specific about what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., tc_list_projects when you don't know the project ID). No mention of preconditions or context for use. The description provides no usage suggestions.
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 available, so the description must disclose behavior. It only states 'list' with no details on read-only nature, required permissions, pagination, ordering, or return format, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what fields are returned, but it does not. It covers basic purpose but lacks details on results, pagination, or limitations for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists todos/notes in a project, distinguishing it from create/update siblings. However, it doesn't explicitly differentiate from other list tools like tc_list_views, but the resource type is different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. It does not mention filtering, search, or any exclusions, leaving the agent to infer 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it 'gets a template' but does not explain return format, side effects, permissions needed, or any constraints. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only 9 words, perfectly concise. It front-loads the essential action and resource with no superfluous information.
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 terse for a tool with no output schema. It fails to explain what a 'complete starter template' entails, how parameters change the result, or what the response looks like. More context is needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain what the 'type' and 'framework' parameters mean or how they affect the output. The agent must rely solely on enum names.
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 clearly states the tool retrieves a complete starter template for a Trimble Connect extension. It uses a specific verb ('Get') and resource ('complete starter template'), and it distinguishes itself from sibling tools that focus on other TC operations like listing topics or views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, scenarios, or exclusions, leaving the agent without context to make an informed selection among siblings.
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 convey behavioral traits. It only states 'create' without disclosing side effects, permissions, idempotency, or return behavior. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero wasted words. Efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema or annotations, the description is too sparse. It does not clarify return values, side effects, or constraints. An agent would lack sufficient information to use this tool confidently.
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 documents all parameters. The description adds no extra meaning beyond what the schema provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (todo/note in a project). It distinguishes from sibling tools like tc_list_todos (list) and tc_update_todo (update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites, scenarios, or exclusions. The description provides no context for decision-making.
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 must disclose behavior. It only states the action without details on recursive listing, pagination, permission requirements, or response structure. This is insufficient.
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 wasted words. However, it could be slightly expanded for completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description is adequate but leaves gaps like pagination and sorting behavior, which are common for list operations.
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 already covers both parameters with descriptions (100% coverage). The description adds no extra meaning beyond what the schema provides, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'contents (files and subfolders) of a folder'. It effectively distinguishes from siblings like tc_search_files (search) and tc_get_file (single file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not mention that for deeper file tree navigation one should use this tool, nor does it contrast with searching tools.
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, and the description does not disclose behavioral traits beyond the basic action. It does not specify if the operation is read-only, whether pagination is supported, what the output structure is, or any side effects. The description carries the full burden but is insufficient.
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. It front-loads the purpose, but could benefit from additional context such as return format or usage hints. Still, it is well-structured for the information provided.
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 list tool with only two parameters and no output schema, the description provides the essential purpose. However, it omits details like whether all clash sets are returned (e.g., pagination) and the output format. It is minimally adequate but not fully complete given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters fully described in the schema (region enum with explanations, projectId as string). The description adds no additional meaning beyond the schema, which already covers parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and explicitly identifies the resource 'clash sets' scoped to 'in a project'. It clearly distinguishes from siblings like tc_clashes (which might be a broader clash tool) and other list tools like tc_list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as tc_clashes or other list tools. No mention of prerequisites, filtering, or pagination. The description simply states the action without context for selection.
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 full burden. It discloses the return format (sections with code examples) but lacks details on authentication, rate limits, pagination, or scope. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It is front-loaded with the primary action and immediately states the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the core purpose and return format. It could mention error behavior or scope limitations, but it provides enough context for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'query' parameter. The description does not add extra information 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 ('Search across all Trimble Connect for Browser API documentation') and the result ('Returns matching sections with code examples'). It distinguishes itself from siblings like tc_search_files (file search) and get_api_reference (specific reference) by focusing on documentation search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_api_reference or list_available_docs. There is no mention of prerequisites, exclusions, or context for selection.
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 must carry full behavioral disclosure. It correctly implies a read-only operation, but does not explicitly state safety (no side effects), auth requirements, or return details. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the core action. Structure is optimal for quick reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no required params, no output schema), the description covers the essential purpose. It could hint at common fields returned, but for minimal tools this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'region' is fully documented in the input schema (100% coverage), including enum and default. The description adds no additional meaning beyond what the schema provides, so 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?
Description clearly states the verb ('Get') and resource ('current authenticated user's profile information'), making the tool's purpose immediately obvious. It is distinct from sibling tools like tc_get_project or tc_users which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusion criteria. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses read-only listing with a region parameter, but omits details like pagination, rate limits, or response structure. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded, no fluff. Perfectly concise and well-structured for the tool's simplicity.
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 list tool with 2 parameters and no output schema, the description adequately covers purpose and key constraint (region). Missing what fields are returned, but the schema covers parameters well. Almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline 3. The description adds no extra meaning beyond the schema for the parameters. Earns its keep by setting context but doesn't improve understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all projects the authenticated user has access to, with a region scope. This distinguishes it from sibling tools like tc_get_project (single project) and tc_create_project (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool, nor alternatives. It's implied when listing projects, but lacks context like 'use tc_get_project for a specific project'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses automatic regional URI resolution, path placeholder filling, and maps each action to HTTP methods and URL patterns. However, it does not cover error handling, permissions, or rate limits, which would elevate transparency further.
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 long due to the many actions listed, but it is well-organized into a numbered list. It could be trimmed by grouping similar actions or using a table, but the structure is functional.
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 fully covers the mapping from actions to URLs and parameters. However, it does not describe return values or outputs for any action, which is a gap since there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value by explaining how the 'action' parameter selects endpoints and how parameters fill path placeholders. This goes beyond the schema definitions.
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 is for the Trimble Connect Property Set Service, covering libraries, definitions, pset instances, policies, and changesets. It distinguishes itself from sibling tools by focusing on property set operations, though it could be more specific about its unique purpose.
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 tells the agent to select an endpoint via the 'action' parameter and lists all actions, but does not provide explicit guidance on when to use this tool versus siblings or when not to use it. The context is implied 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. It mentions executing API calls but doesn't disclose behavioral traits like write operations, rate limits, or error handling. The description is too minimal for a generic API caller.
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 sentences, front-loaded with purpose and usage context. Every word is necessary; no fluff. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately states that it can call any endpoint and supports Core and BCF APIs. It also instructs to use documentation tools first. However, it doesn't explain return values or error handling, which could be improved given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and all parameters have descriptions. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes any Trimble Connect REST API call, specifying Core and BCF APIs. It distinguishes itself from sibling tools that target specific endpoints, providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises using documentation tools first to find the right endpoint, giving context on when to use this tool. However, it doesn't explicitly state when not to use it or list alternatives, but the context is clear enough for an 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 provided; description does not disclose behavioral traits like read-only nature, permissions, or what happens when invoked (e.g., launches UI vs returns data). Merely describes it as 'interactive' without specifics.
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 sentences: first defines purpose, second provides usage context. No unnecessary words; front-loaded with key info.
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?
Covers purpose and usage triggers adequately for a simple dashboard tool with 3 parameters and no output schema. However, lacks behavioral transparency, which reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. Description adds no additional meaning beyond the schema; 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?
Clearly states verb+resource: 'Show an interactive MCP App dashboard for Trimble Connect BCF topics.' Differentiates from sibling tools like tc_bcf_list_topics which lists topics without dashboard interactivity.
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?
Explicitly lists when to use: 'when the user asks for a BCF dashboard, visual BCF summary, filters, charts, or an interactive table.' Does not exclude alternatives, but sibling tools provide obvious 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 fails to disclose side effects (e.g., mutation actions like delete, checkin, checkout, process), required permissions, rate limits, or error states. For a tool with many write operations, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long but well-structured with a list of actions. The initial sentence is dense and could be clearer. While comprehensive, it is not concise; it could be trimmed by focusing on the action selection pattern.
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 complexity (10 parameters, numerous actions, no output schema), the description covers all endpoints and parameter mappings. However, it lacks behavioral context (permissions, error handling) and does not explain return values, which would aid an agent in selecting and invoking correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by mapping actions to specific paths, showing which parameters are needed for each action, and providing body examples for POST/PUT/PATCH actions (e.g., format:'TRB' for process, request bodies for alignment).
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?
Clearly states it is for Trimble Connect Files and lists all possible actions with specific HTTP methods and paths. The description distinguishes itself from simpler sibling tools like tc_get_file by offering a unified interface for many file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to select endpoints via the 'action' parameter and how path placeholders map to input parameters. It provides detailed action examples but does not explicitly guide when to use this tool vs. alternatives like tc_get_file or tc_files_app.
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 lists actions and parameter mapping but fails to disclose behavioral traits such as mutability, idempotency, authentication requirements, rate limits, or error behavior. For a tool handling CRUD operations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise introduction, a general pattern explanation, and a clear bulleted action list. Every sentence serves a purpose; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple actions) and absence of an output schema, the description explains input mechanics well but omits any description of return values, response format, or error states. This is adequate for a REST wrapper but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (baseline 3). The description adds value by mapping each action to its required path parameters (e.g., list requires projectId, get requires id), but this is partially redundant with the schema descriptions that already state 'required when the action path contains {id}'. The action list provides organization but limited new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource: 'Trimble Connect user Groups within a project.' It uses specific verbs via actions (list, get, create, rename, delete, list_users, add_users, remove_users) and distinguishes from sibling tools (e.g., tc_users, tc_todos) by targeting groups specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Select the endpoint with the action parameter' and provides a complete mapping of actions to HTTP methods and path parameters. However, it does not explicitly compare to alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions HTTP methods and path placeholder filling, but does not cover error handling, rate limits, permission requirements, or data irreversibility for destructive actions like delete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-line purpose, a clear explanation of path placeholder mechanics, and a bullet list of actions with HTTP methods and required parameters. Every sentence adds 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?
The description covers actions and parameter mapping, but lacks details on response format (no output schema) and the structure of the 'body' parameter for POST/PUT/PATCH actions. For a complex tool with 10 parameters and 6 actions, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by explaining how path placeholders in the action URLs map to input parameters (e.g., {id} corresponds to the 'id' parameter), which is not explicit in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Trimble Connect Object Links (link entities like todos/files/views to model objects).' It distinguishes itself from sibling tools that focus on individual entities (e.g., tc_todos, tc_files) by specifying it manages links between objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage via the action parameter listing, but lacks explicit guidance on when to use this tool versus alternative sibling tools (e.g., tc_create_todo for creating todos). No 'when to use' or 'when not to use' statements 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?
No annotations were provided, so the description carries full responsibility. It discloses the REST methods (GET, POST, PATCH, DELETE) and actions including delete and remove, but does not discuss side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bullet list of actions and path templates. It is slightly long but mostly concise; every line adds necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, 10 parameters, no output schema), the description covers the main aspects: action selection, parameter mapping, and body usage. It omits return value details, but this is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by linking path placeholders to parameters and noting body usage for certain actions, but the schema already describes each parameter sufficiently.
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 clearly states 'Trimble Connect Releases (file release packages)' and enumerates all actions. The tool is distinct from siblings such as tc_files or tc_folders.
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?
Explains how to select endpoints via the 'action' parameter and how path placeholders map to input parameters, but does not advise when to use this tool vs alternatives like tc_files or tc_list_activities.
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 only states that the tool lists documentation categories and sections. It does not disclose behavioral traits like read-only nature, response format, or what happens if no documentation exists. As a simple list operation, the lack of detail is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is mostly complete. However, it omits what the output looks like (e.g., a list of strings or structured objects). For a simple listing tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so the description does not need to add parameter information. Per calibration rules, 0 parameters yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'all available documentation categories and sections' in the Trimble Connect MCP server. It distinguishes itself from sibling tools like tc_list_activities or tc_list_projects by focusing solely on documentation.
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 search_trimble_connect_docs or get_api_reference. The description simply states what it does, without any context for choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the mapping of actions to HTTP methods and path placeholders. It does not discuss side effects (e.g., mutations from create_export), authorization needs, or return behavior, which are gaps for an audit trail 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 somewhat lengthy but well-structured with a clear introduction and bullet-pointed actions. It front-loads the purpose and organizes information logically. Minor redundancy (e.g., repeating 'action' enum values) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple actions), the description covers the main behaviors and input mapping. The absence of an output schema is mitigated by the action descriptions. It could benefit from examples or default values for optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, but the description adds significant value by explaining how the 'action' parameter selects endpoints and how path placeholders map to input parameters. This provides context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as handling Trimble Connect Activities (audit trail) and activity exports, listing specific actions with endpoints. It distinguishes from sibling tools like 'tc_list_activities' by including exports and logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the 'action' parameter to select endpoints and outlines each action's required parameters. However, it does not explicitly state when to use this tool vs. alternatives like 'tc_list_activities' or other specific tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It does a good job of explaining each action's HTTP method and required IDs, including async deletion and job status. However, it omits details like error responses, side effects (e.g., irreversible deletes), authentication requirements, and rate limits. For a tool with many mutating actions, more transparency would be beneficial.
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 lengthy due to the many actions, but it is well-structured with a clear header, bullet points for each action, and front-loaded with the overall purpose. Each action entry is minimal and informative. While it could be slightly more concise by grouping similar actions (e.g., versions and versions_v21), the structure is effective for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 18 actions) and no output schema, the description is quite complete. It covers all actions, required IDs, and usage of parameters. However, it lacks details on pagination for paged actions (though it mentions paged v2.1 API), error handling, and expected output formats. For a tool with this scope, it is largely adequate but could be enhanced.
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?
Despite 100% schema coverage (baseline 3), the description adds significant meaning beyond the schema. It explains how path placeholders map to parameters (e.g., 'id=folderId'), clarifies that 'items' action uses the project rootId for root, and describes the role of 'body' and 'query' parameters. This context helps the agent correctly invoke each action.
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: 'Trimble Connect Folders: browse, create, rename, delete, versions, permissions.' It then exhaustively lists each action with HTTP method and path, leaving no ambiguity about what operations are supported. This distinguishes it from siblings like tc_get_folder_contents which is specifically for folder contents, as this tool covers a broader set of folder operations.
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 explicit instructions on how to use the tool: select the action via the 'action' parameter and fill path placeholders from matching input parameters. However, it does not provide guidance on when to use this tool versus its siblings (e.g., tc_get_folder_contents, tc_files_app), nor does it mention when not to use it. The usage is clear for each action but lacks comparative 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 discloses HTTP methods and basic behavior (e.g., 'update' uses PATCH), but does not mention side effects, authentication needs, rate limits, or idempotency. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bulleted list of actions. Each sentence provides useful information, though it could be more concise. It is appropriately front-loaded with the general purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a multi-endpoint tool with 10 parameters and no output schema, the description covers action selection, parameter mapping, and path placeholders. It lacks response details but is otherwise complete for its purpose.
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 has 100% coverage with descriptions, but the description adds value by explaining how path placeholders map to parameters (e.g., 'id=userId (or me)' for get action). This enhances understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it covers Trimble Connect Users actions: profiles, update, licenses, timezones, languages. It lists specific actions with HTTP methods and paths, distinguishing it from sibling tools like tc_get_current_user or tc_list_project_users.
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 explains to select the endpoint via the 'action' parameter and lists each action with its path and required parameters. It provides clear context for when to use each action, though it does not explicitly exclude alternatives or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It details HTTP methods (GET, POST, PATCH, DELETE) for each action, which implies mutability for some actions, but does not explicitly state if operations are destructive, require authentication, or have side effects. The description is adequate but lacks explicit warnings.
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 long due to the number of actions but is well-structured with a bullet list grouping actions by sub-resource. The purpose is front-loaded, and each action entry is concise. Some redundancy exists (e.g., repeated path patterns), but overall it balances detail and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 actions, 10 parameters, no output schema), the description is fairly complete. It covers all actions, parameter relationships, and body suggestions. Missing return value details or error handling, but sufficient for selecting and invoking actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The tool description adds value by mapping actions to required parameters (e.g., id=viewId for get, body for create) and explaining how path placeholders fill parameters. This provides practical context beyond the schema alone.
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 handles CRUD operations on Trimble Connect 3D Views, including camera, presentation, section box/planes, and markups. It lists all 20 actions and explains how to select endpoints via the action parameter. This distinguishes it from siblings like tc_list_views (which likely only lists views).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the action parameter and path placeholders, but does not provide explicit guidance on when to use this tool versus more specific sibling tools (e.g., tc_list_views for listing views). It implies this is the single tool for all view operations, but lacks when-not-to-use or alternative suggestions.
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. It fails to mention destructive consequences (e.g., delete action permanently removes data), authorization requirements, rate limits, or idempotency of updates. For a tool with delete and update actions, 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 relatively concise, with three sentences and a bullet list. It front-loads the purpose and action list. However, the bullet list could be more readable (e.g., separating each action into a line). Overall, minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description does a good job explaining how parameters relate to actions. However, it does not describe return values or error handling, which would help agents understand tool output. With no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the input schema by explaining which parameters are required for each action and how path placeholders are filled. The schema alone does not provide this action-parameter mapping, yet coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for Trimble Connect 2D Views and lists the five CRUD actions (list, get, create, update, delete) with HTTP methods and paths. This distinguishes it from sibling tools like tc_views (for views, not 2D views) and tc_bcf_* 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 explains how to choose an action using the 'action' parameter and how path placeholders map to input parameters. It provides explicit mapping for each action, but does not state when not to use this tool or mention alternatives like tc_api_call for custom endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It details the HTTP method, path, and required parameters for each action, including the plumbing of path placeholders. However, it lacks explicit warnings about destructive actions like delete or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise summary and structured as an actionable list. It is efficient but could be slightly more compact by merging redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, 6 actions, no output schema), the description is largely complete, covering routing logic and action-specific details. It omits return value descriptions, but no output schema exists to compensate.
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?
Although schema coverage is 100% (baseline 3), the description adds value by mapping parameters to path placeholders (e.g., 'id=clashId') and explaining that 'body' is for POST/PUT/PATCH. It could be more explicit about query parameters for each action.
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 handles 'Trimble Connect Clash sets (create, inspect, update, delete clash reports)' and enumerates six specific actions with HTTP methods and paths, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to select an action via the 'action' parameter and maps actions to endpoints, but it does not provide guidance on when to use this tool versus sibling tools like 'tc_list_clashsets' or alternative approaches.
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 full burden. It describes HTTP methods (GET, POST, PATCH, DELETE) which imply read/write/destructive behaviors, but it does not disclose required permissions, rate limits, side effects, or error handling. The description covers some behavioral aspects like path parameter filling but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured as a list of actions with consistent patterns (action: HTTP method /path — parameter details). The first sentence clearly sets the scope, and the list format aids readability. However, it could be slightly more concise by grouping similar actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 actions, 10 parameters) and no output schema, the description covers all actions and explains parameter mappings. It lacks information on return values or error responses, which would be helpful for completeness. Overall, it provides sufficient context for most usage scenarios.
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 has 100% description coverage, but the description adds significant value by explaining how parameters like id, subId, extraId, version, and projectId serve as path placeholders. It also provides examples for query parameters (e.g., objectType=TODO) and describes the body parameter. This enhances understanding beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool handles Trimble Connect comments on files, folders, todos, views, etc., including attachments and reactions. It lists 11 specific actions with HTTP methods and paths, and instructs to select the endpoint via the 'action' parameter. This clearly distinguishes it from sibling tools that handle other resources like todos or views.
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 explicit instructions for each action, including the required parameters and HTTP methods. It explains how path placeholders are filled from input parameters. Although it does not explicitly state when not to use this tool or compare it to alternatives, the specific domain of comments makes its usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description compensates by detailing HTTP methods (GET, PATCH, POST, DELETE) for each action, implying read/write/destructive nature. Explains path placeholders and parameter mapping, but could be more explicit about side effects or prerequisites.
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?
Description is front-loaded with purpose and structured as a clear list of actions. Slightly lengthy but each sentence adds unique information. No redundant statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (10 actions, 10 parameters, no output schema), description covers all actions with parameter mapping. Lacks return value descriptions, but actions are standard REST and implied by HTTP method. Adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage. Description adds value by explaining how parameters like id, subId, extraId fill path placeholders, and that body is used for POST/PUT/PATCH/DELETE. Goes beyond simple schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it handles Trimble Connect Companies and company members, enumerates 10 distinct actions (list, get, update, list_users, etc.), and distinguishes from sibling tools which cover other resources (projects, files, BCF topics).
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?
Actions are listed with HTTP methods and paths, but no explicit guidance on when to use this tool vs alternatives among the many tc_* siblings. Usage is implied by resource focus, but lacks 'when-not' or comparison.
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 full burden. It describes the HTTP methods (GET, POST, PATCH, DELETE) and request bodies, implying side effects for mutations. However, it does not explicitly disclose the permanence of deletions, required permissions, or potential side effects like cascading changes. The description provides moderate transparency but leaves some behavioral gaps.
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 long but well-structured with a bulleted list of actions, each briefly described. Some redundancy exists (e.g., repeated path patterns), and it could be more concise while retaining all information. The structure aids readability, but the length is justified by the number of actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 23 actions), the description is remarkably complete. It covers all actions with their HTTP methods, paths, request bodies, and parameter requirements. No output schema exists, but the description sufficiently explains the tool's capabilities. It addresses the need for agents to understand how to invoke different endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds value by explaining when parameters like projectId, id, subId, etc., are required based on the action's path. It also clarifies the 'action' parameter's enum values and the 'region' parameter's meanings. This contextual information goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for 'Trimble Connect Projects administration' and enumerates a comprehensive list of actions (update, delete, clone, members, roles, settings, license, metrics, sync status). This is a specific verb+resource combination that distinguishes it from sibling tools like tc_list_projects or tc_create_project, which are more limited.
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 explains how to select the endpoint via the 'action' parameter and that path placeholders are filled from matching input parameters. It lists all actions with their HTTP methods and paths. However, it does not explicitly state when to use this tool versus simpler alternatives like tc_list_projects or tc_get_project, leaving the decision implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility. It discloses all actions, required IDs, and body structures for writes. It does not mention side effects, auth, or errors, but the level of detail (e.g., path placeholder mapping) is commendable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro followed by a bulleted list of actions. It is front-loaded with the general purpose. Though lengthy, every sentence adds value. Minor redundancy (e.g., repeating body structure) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 9 actions, no output schema), the description covers the action selection, required IDs, and payloads adequately. It lacks output/error details but is fairly complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value by explaining the action parameter's role, mapping IDs to path placeholders, and providing example body fields for create/update. This enriches the schema beyond just property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages Trimble Connect ToDos with full management incl. details, delete, types, attachments. It lists all 9 actions with HTTP methods and required parameters, distinguishing it from siblings like tc_create_todo or tc_list_todos which are more specialized.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to select endpoints via the 'action' parameter and maps each action to HTTP method and path. However, it does not provide guidance on when to use this composite tool versus the more specialized sibling tools (e.g., tc_create_todo, tc_list_todos), leaving the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes the output as an interactive timeline with grouping/filtering, but does not explicitly state that the tool is read-only (no mutations) or mention any required permissions. The behavioral traits are partially disclosed but not comprehensively.
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 concise sentences with no redundant information. The description is front-loaded with the core purpose, and the usage guidance follows naturally. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by explaining the tool returns an interactive timeline (UI component) rather than raw data. It mentions grouping by day and filtering by category. However, it does not specify how the timeline is presented (e.g., within a viewer) or any prerequisites. Still, for a UI-centric tool with good sibling differentiation, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters (limit, region, projectId). The description adds minimal extra meaning beyond mentioning 'latest events' and 'filterable by category'—the latter is not explicitly a parameter. Thus, description adds limited value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays an interactive timeline of recent project events, with specific examples (file uploads, BCF, todos) and grouping/filtering. It distinguishes itself from the sibling tool 'tc_activities' by noting the UI vs plain data difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('when the user asks to SEE the recent project activity') and provides a direct alternative for plain data ('use tc_activities instead'). This gives the agent clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the mapping of path placeholders to input parameters, regional URI resolution, and action selection. It covers CRUD and read operations but does not detail side effects (e.g., deletion permanence) or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to the many actions, but it is well-structured with an initial overview, placeholder explanation, and a detailed action list. Each sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, 21 actions) and no output schema, the description is fairly complete. It covers action-to-endpoint mapping, parameter usage, and regional resolution. It lacks details on return values, but this is partially offset by the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value by explaining how each action maps to parameters (e.g., id=forestId for trees_list). It clarifies the meaning of path placeholders, enabling correct parameter assignment beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for the Trimble Connect Organizer Service, managing forests, trees, nodes, policies, changesets. It lists all actions explicitly and distinguishes from sibling tools which focus on other services like BCF, files, or projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a comprehensive list of actions but does not explicitly state when to use this tool versus alternatives. It lacks comparative guidance or when-not conditions, relying on the agent to infer from the action names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the CRUD actions and parameter-to-endpoint mapping, making behavioral expectations clear (e.g., 'create' modifies data). It could mention idempotency or response behavior, but the actions are self-explanatory.
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 verbose but well-structured with bullet points for actions, making it easy to scan. Every sentence serves a purpose; the length is justified by the complexity of multiple endpoints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter mapping and actions adequately but omits return value information (e.g., what responses look like). Given no output schema, this is a gap, but the core invocation logic is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The tool description adds significant semantic value by linking actions to HTTP methods and specifying which path IDs map to which parameters (e.g., 'id=viewGroupId' for get/update/delete), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages 'Trimble Connect View Groups (organize saved views)' and lists the specific actions (list, get, create, update, delete), distinguishing it from sibling tools like 'tc_groups' and 'tc_views' by focusing on view groups.
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 explicit guidance on using the 'action' parameter to select endpoints, including path placeholder mapping. However, it does not compare with direct siblings like 'tc_groups' or 'tc_list_views', leaving some ambiguity about when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses interactive form behavior, optional prefilling, and capability to attach current 3D viewpoint via viewer bridge. Does not mention auth or rate limits but for a form tool, the main behavioral traits are covered.
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?
Three sentences, front-loaded with main purpose. Every sentence adds value (purpose, prefilling note, viewpoint attachment, alternative). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (7 params, no output schema, no annotations), description explains the interactive form nature, optional prefilling, viewpoint attachment, and distinguishes from sibling. Covers all relevant aspects for a creation-form tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context that parameters are optional prefilled fields, but does not significantly extend beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it shows an interactive form to create a BCF topic, with specific verb 'Show an interactive MCP App form' and resource 'Trimble Connect BCF topic'. Distinguishes from sibling tc_bcf_create_topic by noting alternative for direct creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (user wants to create via form) and provides alternative (use tc_bcf_create_topic + tc_create_viewpoint_from_viewer for direct creation). Lacks explicit 'when not to use' but the alternative serves as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that the viewpoint is created from the live viewer state (camera, selection, snapshot), that the snapshot is attached server-side (never passes through the model), and that the 'Agent Eyes' panel must be open. However, it does not cover potential errors, rate limits, or what happens if the viewer state is not captured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a short typical flow. It front-loads the core purpose and provides necessary details without redundancy. Every sentence adds value, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains the input and source, it does not mention the return value or output format. Since no output schema exists, it would be helpful to state what the tool returns (e.g., viewpoint GUID or success status). Additionally, error conditions or state requirements (e.g., viewer must have loaded a model) are not covered. This is adequate but leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that 'includeSelection' and 'includeSnapshot' correspond to the live viewer state components (IFC GUIDs and PNG snapshot). It also clarifies that the snapshot is attached server-side. This extra context helps an AI understand how parameters relate to the tool's operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a BCF viewpoint'), the resource ('on an existing topic'), and the context ('from the user's LIVE 3D viewer state'). It also mentions specific elements like perspective camera, IFC GUIDs, and PNG snapshot. The tool is well-differentiated from siblings like tc_bcf_create_topic, which creates a topic rather than a viewpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical workflow: first create a topic with tc_bcf, then use this tool with the returned topic GUID. It implicitly indicates when to use (after topic creation and with a live viewer) and the prerequisite of having the 'Agent Eyes' extension panel open. It does not explicitly state when not to use or list alternatives, but the given flow is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'gets all available regions and their API base URLs', implying a read-only operation with no side effects. It does not mention authentication or rate limits, but for a parameterless tool, this is sufficient.
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 concise sentences, front-loaded with purpose. Every word earns its place, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks detail on the return format (e.g., list of objects with name and URL). Given no output schema, the description should be more explicit about the structure to fully aid the agent. It is adequate but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% (empty schema). Baseline 4 applies per rules, and the description does not need to add parameter info as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all Trimble Connect regions and their API base URLs, and indicates it should be called first to determine the region. This is a specific verb+resource that distinguishes it from sibling tools that deal with topics, todos, files, etc.
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 guidance on when to use this tool: 'Call this first to determine which region a project is in.' It implies usage context but does not explicitly mention alternatives or when not to use it, which is acceptable for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses all actions, their HTTP methods, path placeholders, and which parameters are required per action. It implies that create requires a body, update patches fields, etc. It does not mention authentication or rate limits, but the behavioral traits are well covered for a sharing 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 moderately long but well-structured: a brief purpose statement, then a bulleted list of actions. Every sentence is informative. It could be slightly more concise by grouping common patterns, but overall it's efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and 6 actions, the description covers the essential: how to select actions and map parameters to paths. It doesn't describe response format or error conditions, but with no output schema, that's acceptable. It provides enough context for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description adds significant value by mapping parameters to path placeholders (e.g., id=shareId, subId, extraId, version) and specifying which action uses which. For example, 'get_by_token' uses 'id' as share token. This clarifies parameter roles beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for sharing files/views with external users via Trimble Connect. It lists specific actions (list, get, create, etc.) that distinguish it from sibling tools like tc_files, tc_folders, etc. The verb 'share' and resource 'Shares' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that the 'action' parameter selects the endpoint and lists each action with its HTTP method and path. While it doesn't explicitly say when not to use this tool, the context makes it clear that it's for external sharing, and the detailed action list guides usage. No alternative tools are mentioned, but the purpose is distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the CRUD operations and object association actions, including destructive ones like 'delete' and 'remove_objects'. However, it lacks details on authentication, rate limits, or side effects beyond the operation 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 efficiently structured: a high-level purpose followed by a clear bulleted list of actions with their HTTP methods, paths, and parameter requirements. No redundant sentences; each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all actions and parameter mappings for a multi-action tool. However, it lacks information about return values or error handling, which is notable given the absence of an output schema. Nonetheless, it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema by mapping each action to the required parameters (e.g., 'id=tagId' for get/update/delete) and explaining path placeholders. With 100% schema coverage, the description still clarifies parameter usage per action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for 'Tag files, folders and other objects' and lists all actions (list, get, create, update, delete, list_objects, add_objects, remove_objects). This clearly distinguishes it from sibling tools like tc_files or tc_folders which manage different resources.
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 by mapping actions to HTTP methods and required parameters. It explains how to select the endpoint via the 'action' parameter. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output (camera, selections, models) and requisite (extension open). It implies a read-only operation and warns about staleness, but doesn't explicitly state side effects or authentication needs. Overall transparent enough for a read 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?
Very concise: three sentences that flow logically from purpose to prerequisite to usage advice. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly describes what is returned and includes actionable guidance (extension requirement, staleness check). Covers all necessary context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% (empty). Description correctly adds no unnecessary parameter info. Baseline 4 applies as there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the live state of the user's 3D viewer, listing specific components (camera, selected objects, models, snapshot). It explicitly says when to use it (requests about what user currently sees), distinguishing it from sibling tools like get_current_user or tc_list_views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use when referring to current view, requires 'Agent Eyes' extension to be open, and advises checking age_seconds/stale. However, no explicit alternatives or when-not-to-use guidance given, but the usage advice is sufficiently directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool displays an interactive card with inline actions and special internal parameter (snapshotViewpointId). It does not claim destructive behavior or contradict any annotations, though it could mention that inline actions are UI triggers, not executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by usage guidance and alternatives. It is slightly lengthy but each sentence adds value, earning a 4.
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?
Despite lacking an output schema, the description adequately explains the return is an interactive MCP App card and lists its contents (description, status, priority, comments, viewpoints, actions). It provides sufficient context for the agent to understand what the user will see.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the special purpose of snapshotViewpointId and the need to resolve topicId from a title, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows an interactive MCP App card with full detail of a BCF topic, listing specific fields (description, status, priority, comments, viewpoints) and distinguishing from the sibling tool tc_bcf action topic_get which returns plain data without UI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when the user asks to SEE the detail'), provides a prerequisite (resolve topic GUID via tc_bcf action topics_list if the user gave a title), and names an alternative (tc_bcf action topic_get for plain data).
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 provided, so description must carry the burden. The description implies read-only diagnostic behavior but does not explicitly state side effects or authorization needs. However, the nature of a debug tool suggests safety.
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 concise sentences: first defines purpose, second provides usage guidance. No unnecessary words, front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter debug tool without output schema, the description adequately covers what it returns (identities and match status) and when to use it. No gaps identified.
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 no parameters, and schema coverage is 100%. The description explains the return values, which adds meaning beyond the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a diagnostic tool for the viewer bridge, returning identity information and match status. This distinguishes it from sibling tools which are focused on BCF, views, or other features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: only when get_current_viewer_state or tc_create_viewpoint_from_viewer report no viewer state. This provides clear usage context and excludes normal situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It discloses the interactive table display, version history expansion, and internal use of fileId. Lacks details on authentication or rendering specifics, but sufficient for a display 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?
Three sentences with no fluff: first sentence defines function, second gives usage with example, third clarifies alternatives and fileId purpose. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains the interactive output (table with expandable versions). Could mention column details, but not necessary for an app tool. Covers key use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining fileId's role ('used internally by app UI') and context for limit. No further detail 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?
The description clearly states the tool shows an interactive MCP App table of recent files, with version history expansion on click. It distinguishes itself from sibling tc_files (plain data) and mentions alternative usage with fileId. The verb 'Show' and resource 'table of latest files' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'when the user asks to SEE/DISPLAY recent files' with an example query. Also states when not to use: 'For plain data without UI, use tc_files instead.' This provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description indicates it displays an interactive table but doesn't explicitly state read-only behavior or other traits. However, the purpose implies non-destructive use, and the output format is described.
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 concise sentences, front-loaded with purpose, followed by usage guidelines and alternative. No wasted words, easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, output fields, and alternative tool. It is adequate for a simple display tool, though it could mention any prerequisites like viewer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by mentioning 'latest project ToDos' and listing displayed fields, providing meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows an interactive table of latest ToDos with specific fields. It explicitly distinguishes itself from the sibling tool tc_todos, which provides plain data without UI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (user asks to SEE/DISPLAY) and when not to (use tc_todos for plain data). It also provides example queries, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the burden. It discloses that the tool shows an interactive UI with action buttons (create BCF, create ToDo, show properties), implying potential side effects if buttons are clicked. However, it does not explicitly state whether the tool itself mutates any state. With annotations missing, this is a reasonable level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose, usage context, prerequisite, and alternative. It is front-loaded with the primary action and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description covers all necessary context: what it does, when to use, what it requires, and a sibling alternative. There is no missing information for an agent to decide when to invoke this 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 input schema has zero parameters and 100% schema description coverage. The description adds no parameter information because none exists. Baseline 4 is appropriate as there is no need for parameter explanation.
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 shows an interactive MCP App that reviews selected objects in the 3D viewer. It specifies the resource (current selection) and actions (review, with buttons). It also distinguishes itself from the sibling get_current_viewer_state by noting the UI vs plain data difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user asks to review/see their current selection'. Provides a clear alternative: 'For plain data without UI, use get_current_viewer_state instead'. Also includes a prerequisite: 'Requires the Agent Eyes panel open'.
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:

[![trb-mcp-server-api MCP server](https://glama.ai/mcp/servers/SimonTrim/trb-mcp-server-api/badges/card.svg)](https://glama.ai/mcp/servers/SimonTrim/trb-mcp-server-api)

Score Badge

Copy to your README.md:

[![trb-mcp-server-api MCP server](https://glama.ai/mcp/servers/SimonTrim/trb-mcp-server-api/badges/score.svg)](https://glama.ai/mcp/servers/SimonTrim/trb-mcp-server-api)

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/SimonTrim/trb-mcp-server-api'

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