Enterprise MCP Template

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. The CRUD operations (create_record, get_record, update_record, delete_record) are well-separated from query execution (execute_query), schema retrieval (get_record_schema), and health checks (health, ping). The descriptions clearly differentiate each tool's function, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case throughout. The naming is predictable and readable, with verbs like create, delete, execute, get, and update paired with appropriate nouns like record, query, schema, or simple actions like ping/health.
Tool Count5/5
The 8 tools are well-scoped for an enterprise API template server. This includes complete CRUD operations, query execution, schema retrieval, and health checks, which is appropriate for interfacing with various upstream APIs. Each tool earns its place without feeling excessive or insufficient.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for record management (create, get, update, delete), plus essential utilities like query execution, schema documentation, and health checks. There are no obvious gaps for the server's purpose of interacting with enterprise APIs, and agents can perform all expected operations without dead ends.
Average 3.3/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but omits critical safety context: no idempotency guarantees, no conflict behavior (what if record exists?), no rate limits, and no auth scope requirements. The Returns section adds value by describing the response structure beyond the existence of an output schema.
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 wastes prime real estate with meta-commentary ('Replace this docstring with your domain-specific documentation') intended for developers rather than AI agents. While the Args/Returns structure is logical, the template noise undermines front-loading of essential 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 presence of the TEMPLATE warning indicates incomplete documentation. While the Args section covers parameters and Returns covers output, the description lacks domain specificity (what kind of records? what API?) and operational context (error scenarios, validation rules) expected for a 4-parameter mutation 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?
Despite 0% schema description coverage, the Args section compensates effectively by documenting all 4 parameters with types, optionality logic (account_id 'required if not configured on server'), and usage examples (record_type examples: 'customer', 'invoice'). This is strong compensation for the schema deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a clear verb-resource pair ('Create a new record'), but the description is polluted with template placeholder text ('TEMPLATE: Replace this docstring...') that signals incomplete implementation. It fails to distinguish from sibling update_record or clarify record creation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use create_record versus update_record or execute_query. The only contextual clue is in the account_id parameter description mentioning server configuration, but this is implicit rather than prescriptive guidance.
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, leaving full burden to description. States it returns 'Structured response with query results' but fails to disclose if this is read-only (implied by name but not explicit), rate limits, authentication requirements, or error handling behavior. Template nature suggests incomplete behavioral documentation.
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?
Well-structured with clear Args/Returns sections, but contains inappropriate template placeholder text ('TEMPLATE: Replace with...') that wastes space and reduces clarity. Otherwise efficiently organized.
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?
Describes the 5 parameters and mentions return structure, adequate for a query tool. However, lacks safety disclosures (despite being likely read-only) and edge case handling given zero annotations and incomplete template status.
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 0% schema description coverage, the Args section effectively compensates by documenting all 5 parameters: query language syntax, account_id conditional requirements, base_url override behavior, and pagination controls (limit/offset). Adds meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the tool executes queries against an upstream API and lists example query languages (SuiteQL, SOQL, GraphQL), but contains placeholder template text ('TEMPLATE: Replace with...') indicating incomplete customization. Distinguishes from CRUD siblings (create_record, delete_record) by nature of being a query operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_record (which likely retrieves single records by ID). The Args section explains parameter mechanics but not selection criteria or prerequisites for using 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a read operation that returns documentation, but lacks details on the format of returned schema (JSON Schema?, OpenAPI?), caching behavior, or whether the schema is static or dynamic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains obvious template placeholder text ('TEMPLATE: Replace with your domain-specific schema documentation') that serves no purpose for the AI agent and indicates an unfinished implementation. This meta-text wastes tokens and creates confusion.
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?
While the context signals indicate an output schema exists (reducing the description's burden to explain return values), the presence of template text suggests the tool definition is incomplete. For a schema introspection tool with no parameters, the description should specify what format the schema documentation takes (e.g., JSON Schema, field listings).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema correctly reflects this with 'additionalProperties: false'. Per evaluation guidelines, zero-parameter tools receive a baseline score of 4 since there are no parameter semantics to describe beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first two sentences clearly state the tool retrieves schema/structure information for record payloads. However, the inclusion of 'TEMPLATE: Replace with your domain-specific schema documentation' indicates placeholder content that pollutes the description and creates ambiguity about whether this is a fully implemented tool or a stub.
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 implied usage guidance by stating it 'helps AI clients construct correct payloads,' suggesting it should be used when preparing data for create/update operations. However, it lacks explicit guidance on when to prefer this over siblings (e.g., 'Call this before create_record').
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, so description carries full burden of behavioral disclosure. Fails to specify critical mutation traits: whether updates are partial (PATCH) or full replacement (PUT), what happens if record_id doesn't exist, idempotency guarantees, or error handling behavior. Only mentions 'Structured response' without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized docstring format with clear Args and Returns sections. Front-loads the core purpose in the first sentence. No redundant or filler text, though 'upstream API' could be more specific.
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?
Adequate for parameter documentation given the input schema lacks descriptions, and output schema exists so return values need minimal explanation. However, as a mutation tool with zero annotations, it lacks important operational context regarding failure modes, authentication requirements, and update semantics that would be necessary for safe 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?
Excellent compensation for 0% schema description coverage. The Args section documents all 5 parameters including helpful examples (e.g., 'customer', 'invoice' for record_type), conditional requirement logic for account_id, and the override relationship between base_url and account_id. Only minor gap is lack of detail on valid values within the updates dictionary.
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?
States 'Update an existing record' with clear verb and resource type. The phrase 'existing record' usefully distinguishes from sibling create_record. However, 'upstream API' is vague jargon that doesn't specify the domain or system being interacted with.
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?
Provides no explicit guidance on when to select this tool versus create_record or other alternatives. Missing crucial prerequisite context such as 'use only when record exists' or guidance on how to check existence via get_record first.
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, description carries full burden. It successfully discloses conditional auth requirements (account_id only required if not server-configured) and parameter precedence (base_url overrides account_id). However, it fails to state that deletion is permanent/irreversible or describe error conditions.
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?
Uses structured docstring format (Args/Returns) that is front-loaded with the core action. Slightly verbose given the Returns section repeats what the output schema already provides, but every line conveys useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and 0% schema coverage, the description successfully documents all inputs. Acknowledges return value existence without duplicating the output schema. Only gap is missing warning about destructive nature given lack of destructiveHint annotation.
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 has 0% description coverage, but the description comprehensively documents all 4 parameters: record_type (with examples), record_id (semantics), account_id (conditional requirement), and base_url (override behavior). Fully compensates for schema deficiency.
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?
States specific verb (Delete) and resource (record) and distinguishes from siblings create_record/update_record/get_record. 'Upstream API' is slightly vague context, but the core purpose is unmistakable.
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?
Provides no guidance on when to use this versus update_record or create_record, nor does it warn that deletion is permanent. The Args section explains parameter mechanics but not usage strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value structure ('Structured response with record data') but omits error handling (404 behavior), authentication requirements, rate limits, or caching behavior that would help an agent understand operational constraints.
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 docstring-style format with Args and Returns sections is structured and readable. Every sentence provides value, though the formatting is slightly unconventional for MCP descriptions. Given the zero schema coverage, the verbosity is necessary and appropriate.
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?
Considering the 5 parameters with zero schema coverage, the description successfully documents all inputs. Since an output schema exists, the brief Returns statement is sufficient. It lacks only error scenario documentation to be fully complete for a retrieval operation.
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 schema has 0% description coverage, making the description's Args section critical. It excellently compensates by documenting all 5 parameters: record_type includes examples ('customer', 'invoice'), account_id explains conditional requirement logic, and base_url clarifies the override relationship to account_id.
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 fetches a record 'by ID' from an upstream API, using specific verb (Fetch) and resource (record). The 'by ID' qualifier helps distinguish it from sibling execute_query, though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like execute_query (for queries) or get_record_schema (for metadata). The description only implies usage through the parameter documentation without stating when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value ('pong') and the basic operation, but lacks details on failure modes, timeout behavior, authentication requirements, or side effects that would be expected for a complete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of 11 words that immediately communicates the tool's purpose without waste. Every word 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?
Given the tool has zero parameters, an output schema exists (reducing the need to document return values), and the operation is trivial, the description is adequate. It would benefit from clarifying the distinction from the 'health' sibling tool, but is otherwise complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. Per the rubric, zero-parameter tools receive a baseline score of 4 since no parameter explanation is required in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'ping/pong health check' that returns 'pong' if responsive, using specific verbs and identifying the resource. However, it does not differentiate from the sibling 'health' tool, leaving ambiguity about which health-checking tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it checks if 'the server is responsive,' but provides no explicit guidance on when to prefer this over the sibling 'health' tool, nor any prerequisites or conditions for use.
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 successfully discloses return payload contents (server status, configuration validity, version information). Could improve by explicitly stating it's read-only/safe, but adequately covers the key behavioral trait for a health endpoint.
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 with zero waste. First establishes purpose, second details return values. Perfectly front-loaded and appropriately sized for tool 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 0 parameters and existence of output schema (per context signals), description provides sufficient context by disclosing the nature of returned information. Complete for a simple health-check tool, though mentioning read-only nature would provide full coverage.
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?
Zero parameters present. Per rubric, 0 params = baseline 4. The description correctly avoids inventing parameter semantics where none exist.
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?
Specific verb ('Health check') + resource ('MCP server') clearly stated. The return value details (status, configuration validity, version) effectively distinguish it from sibling 'ping' (likely a simple connectivity check), establishing a distinct 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?
No explicit 'when to use' or comparison to sibling alternatives provided. While 'health check' is self-explanatory, the description doesn't state prerequisites or when to prefer this over 'ping' for connectivity checks.
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

Enterprise MCP Template MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![Enterprise MCP Template MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/victor-velazquez-ai/enterprise-mcp-template/badges/card.svg)](https://glama.ai/mcp/servers/victor-velazquez-ai/enterprise-mcp-template)

Score Badge

Copy to your README.md:

[![Enterprise MCP Template MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/victor-velazquez-ai/enterprise-mcp-template/badges/score.svg)](https://glama.ai/mcp/servers/victor-velazquez-ai/enterprise-mcp-template)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![Enterprise MCP Template MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fvictor-velazquez-ai%2Fenterprise-mcp-template%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/victor-velazquez-ai/enterprise-mcp-template)

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/victor-velazquez-ai/enterprise-mcp-template'

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