contractoracle
Server Details
ContractOracle - 10 contract analysis tools: clause extraction, redlines, DORA mappings.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/contractoracle
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3/5 across 11 of 11 tools scored.
Each tool targets a distinct aspect of DORA compliance: CIF analysis, clause validation, AI deep analysis, expiration tracking, gap identification, risk scoring, exit readiness, server health, contract listing, registration, and subcontracting chain mapping. No two tools have overlapping purposes.
Most tool names use snake_case, but the pattern is inconsistent: some start with a noun (cif_analysis, clause_check), some with a verb (list_contracts, register_contract), and some are compound nouns (subcontracting_chain). 'contract_analyze_llm' uses a verb after the noun, breaking the verb_noun convention.
With 11 tools covering contract lifecycle, compliance checks, risk analysis, and subcontracting, the count is well-scoped for a DORA compliance server. Each tool serves a clear purpose without redundancy.
The tool set covers registration, listing, clause validation, gap analysis, risk scoring, CIF analysis, exit readiness, subcontracting, and expiry tracking. Minor gaps include no dedicated contract retrieval by ID (though list_contracts may filter) and no delete tool, but these are not critical for the core compliance workflow.
Available Tools
11 toolscif_analysisBInspect
Analyze all Critical/Important Function contracts for enhanced Art. 30(3) requirements.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action ('analyze') without disclosing whether operations are read-only, whether permissions are needed, or what happens to the data. The term 'analyze' implies non-destructive behavior, but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no extraneous words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context on what the analysis output includes and does not explain the term 'enhanced Art. 30(3) requirements', which may be unclear to an AI agent. Given no parameters and no output schema, the description is adequate but not fully complete for an unfamiliar agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so schema description coverage is 100%. The description does not add anything beyond this, but since no parameters exist, it is appropriately handled. A baseline score of 4 is suitable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Critical/Important Function contracts for enhanced Art. 30(3) requirements. It uses a specific verb and resource, and the mention of CIF and Art. 30(3) distinguishes it from siblings like contract_analyze_llm. However, it could be more precise about what 'enhanced Art. 30(3) requirements' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like contract_analyze_llm or clause_check. It does not specify prerequisites, exclusions, or the intended context for analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clause_checkCInspect
Validate a contract against all DORA Art. 30 mandatory clauses (standard + CIF).
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Tool Definition Quality
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. It states the action ('validate') but does not disclose whether the tool is read-only, has side effects, or how it behaves (e.g., output format, latency). Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 but could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter, no output schema, no annotations), the description is insufficient. It omits crucial details like the output format (e.g., pass/fail, list of missing clauses) and any error or edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add meaning. However, it provides no explanation of the single parameter 'contract_id' (e.g., expected format, source). The parameter name is self-explanatory, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Validate') and a well-defined target ('contract against all DORA Art. 30 mandatory clauses (standard + CIF)'). This distinguishes it from siblings like 'contract_analyze_llm' which likely performs general contract analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (DORA compliance) but offers no explicit guidance on when to use this tool versus alternatives like 'contract_analyze_llm' or 'contract_gaps'. No when-not or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_analyze_llmAInspect
AI-powered deep analysis of contract text against DORA Art. 30(2) mandatory clauses using local Gemma 4 LLM. Provide raw contract text or a contract_id for structured analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Raw contract text to analyze | |
| contract_id | No | Existing contract ID for structured analysis |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions using a local Gemma 4 LLM for analysis, which indicates AI usage and local processing, but does not clarify read-only nature, error handling, or response format. More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding value. The first sentence states the core functionality and target regulation, the second explains input options. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an AI analysis tool and the absence of output schema, the description lacks details about the output format (structured report, summary, etc.) and how to interpret results. Sibling tools may compensate, but the description alone is somewhat incomplete for new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the schema (100% coverage). The description adds context by explaining the trade-off between providing raw text or a contract_id for structured analysis, and clarifies that analysis targets DORA Art. 30(2) clauses, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs deep analysis of contract text specifically against DORA Art. 30(2) mandatory clauses using a local LLM. This distinguishes it from sibling tools like clause_check (general clause checking) or contract_gaps (gap identification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two input options (raw text or contract_id) but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Some guidance is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_expiryCInspect
Upcoming contract expirations and renewal deadlines.
| Name | Required | Description | Default |
|---|---|---|---|
| days_ahead | No | Lookahead window (default 180 days) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but does not disclose behavioral traits such as read-only nature, output format, or any limits. Adding context about pagination or result structure would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single 6-word sentence. It is front-loaded and to the point, though it sacrifices some completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values. It only states the topic but not what the tool returns (e.g., list of contracts, dates). This is insufficient for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter, so baseline is 3. The description adds no extra meaning beyond the schema, but also does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool deals with upcoming contract expirations and renewal deadlines, differentiating it from general listing tools like list_contracts. However, it lacks an action verb, using a noun phrase instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings such as list_contracts or contract_gaps. It does not state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_gapsBInspect
Identify missing mandatory clauses across all contracts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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 behavioral traits such as performance implications for scanning 'all contracts', resource usage, or side effects like potential large return sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. For a simple tool with no parameters, this concise structure is appropriate, though it could be slightly more detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally complete. However, it lacks context about the scope of 'all contracts' and potential performance considerations, which could affect an agent's decision to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description adequately covers the input schema. No additional parameter semantics are needed, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying missing mandatory clauses across all contracts. It uses a specific verb-resource combination, distinguishing it from siblings like 'clause_check' or 'contract_analyze_llm'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention when not to use it or compare with sibling tools like 'cif_analysis' or 'contract_scoring'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_scoringCInspect
Red-flag risk scoring: exit risk, lock-in, jurisdiction, subcontracting gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It only hints at what the tool evaluates (risks) but does not disclose whether it is read-only, how scoring works, or what output to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with risk types. However, it omits necessary context, making it borderline between efficient and under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description lacks completeness. It does not explain the scoring output, how to interpret results, or any preconditions (e.g., contract must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should clarify parameters. It does not explain the contract_id parameter beyond its existence, leaving the agent without guidance on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Red-flag risk scoring' and lists specific risk types (exit risk, lock-in, jurisdiction, subcontracting gaps). It distinguishes itself from sibling tools like contract_analyze_llm (broader analysis) and clause_check (specific clauses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exit_readinessCInspect
Evaluate exit plan readiness for a contract — Art. 28(8) exit strategies.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'evaluate'—it does not disclose whether the tool is read-only, modifies state, requires auth, or has side effects. The behavioral traits are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, very concise. However, it sacrifices completeness for brevity, missing information that would justify its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations, the description is incomplete. It does not explain the output format (e.g., score, pass/fail) or prerequisites, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the single parameter 'contract_id' beyond its name. No format, constraints, or context are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it evaluates exit plan readiness for a contract, with a specific reference to Art. 28(8) exit strategies. This distinguishes it from sibling tools like 'health_check' or 'contract_analyze_llm', though it could be more explicit about what 'readiness' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 lacks any context about prerequisites, exclusions, or recommended scenarios for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkCInspect
Server status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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. 'Server status.' does not disclose whether the tool performs a simple read, requires authentication, or has side effects. Returns are unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words). While concise, it could be structured to include expected output or response format without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 should at least hint at the return value or status format. It lacks completeness for an agent to know what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Schema description coverage is 100% by default. The description adds no additional parameter meaning, which is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Server status.' clearly indicates the tool checks server status, but lacks specificity on what aspects of status are reported (e.g., health, uptime, connectivity). It is distinguishable from sibling tools which are contract-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Given no parameters and a self-explanatory function, it may be used routinely, but the description provides no context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_contractsCInspect
List contracts with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| is_cif | No | ||
| provider | No | ||
| expiring_days | No | Show contracts expiring within N days |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'List' implies a read operation but does not explicitly state whether it is read-only, what the response format is, or any constraints like authentication or rate limits. The description 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point. While concise, it lacks structure and could be more informative without losing brevity. It is not overly verbose, but the trade-off is insufficient detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of sibling tools and three parameters with no output schema, the description is too minimal. It does not explain the context of contracts, what the filters do, or what the output contains, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (expiring_days) has a schema description. The tool description adds no additional meaning to the parameters beyond 'optional filters.' Schema coverage is 33%, so the description does not compensate for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List contracts with optional filters' clearly indicates the action (list) and the resource (contracts). However, it does not differentiate from sibling tools like 'contract_expiry' which also deal with contracts, but listing is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. The 'optional filters' mention is vague and does not help an agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_contractBInspect
Add or update an ICT third-party contract. Tracks all DORA Art. 30 mandatory clauses.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| is_cif | No | Supports critical/important function? | |
| contract_id | No | ||
| audit_rights | No | ||
| auto_renewal | No | ||
| contract_end | No | ||
| jurisdiction | No | ||
| data_location | No | ||
| exit_strategy | No | ||
| governing_law | No | ||
| notice_period | No | ||
| provider_name | Yes | ||
| sub_providers | No | ||
| contract_start | No | ||
| contract_title | No | ||
| sla_definition | No | ||
| data_protection | No | ||
| annual_value_eur | No | ||
| escrow_source_code | No | ||
| function_supported | No | ||
| termination_rights | No | ||
| business_continuity | No | ||
| cooperation_authority | No | ||
| full_sla_quantitative | No | ||
| incident_notification | No | ||
| availability_guarantee | No | ||
| performance_monitoring | No | ||
| subcontracting_conditions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'add or update' without disclosing mutation specifics, such as whether updates require an existing contract_id, permissions needed, or potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and key context (DORA compliance). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 28 parameters (most undocumented), no output schema, and no annotations, the description is far too minimal. It does not explain how to perform updates, required fields beyond provider_name, or return behavior, leaving a large gap for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 4% (only is_cif has a description). The description's mention of 'DORA Art. 30 mandatory clauses' provides some context for the many boolean parameters, but does not explain individual parameters like contract_start, jurisdiction, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('add or update') and the resource ('ICT third-party contract'), and distinguishes itself from sibling tools like list_contracts (listing) and contract_analyze_llm (analysis) by focusing on registration and DORA compliance tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for contracts requiring DORA Art. 30 compliance but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subcontracting_chainCInspect
Map and assess the subcontracting chain of a contract (RTS on subcontracting).
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Tool Definition Quality
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, data access patterns, or required permissions. The term 'assess' suggests analysis but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the core purpose without extraneous information. However, it is perhaps too terse for full understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is minimal and does not explain what 'map and assess' entails or what the output will be. The agent lacks critical context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'contract_id' has no description in the schema, and the tool description does not add meaning beyond its name. With 0% schema coverage, the description should compensate but fails to clarify the parameter's format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Map and assess' and the resource 'subcontracting chain of a contract', distinguishing it from sibling tools that focus on other contract aspects. However, the acronym 'RTS' may be unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, or any prerequisites. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!