show_version
Read-onlyIdempotent
Show the current MCP platform and adapter versions.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
SINTEGRA: SP
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific scope of what versions are shown ('MCP platform and adapter'), but does not go beyond that to describe return format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object, and contains zero wasted words. It is optimally concise.
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, no-output-schema version query, the description fully conveys what the tool returns. It is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is trivially fully covered (100%). The description needs no parameter explanation; this baseline of 4 is appropriate since the tool takes no input.
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 ('Show') and resource ('current MCP platform and adapter versions'), clearly distinguishing this from sibling tools like authenticate or connect. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like toolkit_info, or when version info might be needed. The description implies usage by stating what it does, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.5/5.0
Disambiguation2/5
The marketplace tool is a monolith covering search, describe, invoke, install, subscribe, cancel, report_bug, request_mcp, and prompt library actions, while separate report_bug and connect tools overlap with it. Existing overlaps (connect vs toolkit_info status, authenticate vs connect) create ambiguity. An agent would struggle to decide whether to use marketplace or the dedicated tool.
Naming Consistency2/5
Tool names mix bare verbs (connect, authenticate), nouns (marketplace), verb_noun compounds (report_bug, show_version, sintegra_sp_consultar), and noun_noun (toolkit_info). No consistent verb-object pattern; styles vary between snake_case and words without delimiters, making predictions unreliable.
Tool Count4/5
Seven tools is within the typical well-scoped range for a platform toolkit. The count is reasonable, though the marketplace tool shoulders many responsibilities and could be split; still, the overall number is appropriate.
Completeness4/5
The server covers authentication, connection status, MCP discovery/execution, billing controls, feedback, version info, toolkit state, and a specific data lookup. Minor gaps like user preference management are absent, but core workflows are represented. The inclusion of sintegra_sp_consultar appears domain-specific but does not create a dead end.