Shodai Agreements

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool targets a distinct action or resource. There is no ambiguity between deploy, get, list, preflight, prepare, submit, validate operations. Even similar-sounding tools like get_agreement and get_agreement_document are clearly differentiated by their descriptions and return types.
Naming Consistency5/5
All tool names consistently use snake_case with a verb_noun pattern. The verbs are descriptive (deploy, get, list, preflight, prepare, submit, validate) and the nouns accurately reflect the resource or context. Naming is predictable and systematic.
Tool Count5/5
With 11 tools covering the full lifecycle of agreement management—from validation and preflight to deployment, state queries, and input submission—the count is well-scoped. Each tool serves a clear purpose without redundancy or bloat.
Completeness4/5
The tool set covers the core workflows: validation, deployment preparation/signing, deploying, reading agreements/documents/state, listing, submitting inputs, and inspecting history. Missing are update/amend or delete/terminate operations, but these may be outside the domain's scope given the immutable nature of deployed agreements.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 71 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description confirms the read-only nature ('does not deploy, does not require signature') and adds the required scope ('agreements.write'), but does not provide additional behavioral details beyond what annotations already communicate.
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 concise sentences: first states purpose and inputs, second clarifies non-deployment and non-signing, third gives usage guideline and scope. Every sentence adds value, no redundant text, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, nested objects, no output schema, and moderate complexity. The description lacks any mention of what the tool returns (e.g., validation result, boolean, error messages), leaving an agent uncertain about the response format. This is a significant gap.
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 each parameter having a description. The description summarizes the five parameter groups ('agreement JSON plus target chain, deployment values, participant wallet mappings, and observer context'), but does not add new semantic meaning beyond what the schema provides. 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 tool checks readiness for deployment, explicitly clarifies it does not deploy or require a signature, and distinguishes itself from the sibling deploy_agreement. The verb 'checks' plus resource 'agreement plus inputs' is specific.
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 when-to-use guidance: 'Always run this before signing a deploy permit.' It also contrasts with deploy_agreement by stating it does not deploy. However, it does not mention when not to use it or how it differs from validate_agreement, a potential sibling alternative.
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?
Annotations already indicate destructive and non-readOnly behavior. The description adds value by explaining the permit flow, the need for preflight, and that the API submits an on-chain transaction and returns a record. This context enriches understanding beyond 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?
Three sentences, each earning its place: the first explains the core action, the second outlines the permit workflow, and the third gives a prerequisite and scope. No fluff, front-loaded with the most critical 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?
Given 13 parameters, nested objects, and no output schema, the description adequately explains what the tool does, what it returns, and the essential workflow steps. It covers prerequisites (preflight) and auth scope, making it complete for its complexity.
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 detailed descriptions, so baseline is 3. The narrative description adds high-level context about permit components (signer, deadline, signatures) and references prepare_deployment_typed_data, but does not significantly elaborate 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 verb 'deploys', the resource 'authored agreement JSON', the mechanism 'EIP-712 permit', and the outcome 'returns the deployed agreement record'. It also distinguishes from sibling tools by mentioning alternatives like prepare_deployment_typed_data.
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 states to 'Always run preflight_deployment before deploying' and 'Requires the agreements.write scope'. It also provides context on when to use prepare_deployment_typed_data first. It lacks explicit 'when not to use', but the guidance is clear and actionable.
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?
The description adds behavioral context beyond the annotations by listing the returned fields (content type, display name, chain, etc.). Annotations already declare readOnlyHint, idempotentHint, and no destructiveness, so the description complements them well without contradiction.
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 cover purpose and usage guidance with zero fluff. All information is front-loaded and necessary.
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 single-parameter tool with no output schema, the description adequately explains what is returned (list of fields). It could be more complete with response structure details, but the listed fields provide sufficient 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?
The input schema description for documentId already states the same sourcing guidance as the tool description. With 100% schema coverage, the description does not add significant new meaning beyond what the parameter description provides.
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 ('Returns the rendered hosted prose document') and resource ('agreement by documentId'). It lists the specific content fields included, distinguishing it from sibling tools like get_agreement (which likely returns metadata) and list_agreements.
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 tells the agent where to obtain the documentId ('Use documentId from list_agreements/get_agreement or from prepare_deployment_typed_data'), providing clear sourcing guidance. While it doesn't state when not to use it, the context is sufficient for this read-only lookup.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds valuable context about interpreting state relative to the lifecycle, which goes beyond annotation signals.
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, no unnecessary words. Every sentence adds value.
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 is provided, which might be a gap, but the description sufficiently explains the return value's semantics and usage pattern. For a simple state-retrieval tool, 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% with a well-described single parameter. The tool description does not add additional parameter meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('Returns') and resource ('state of an agreement'), distinguishes from siblings like get_agreement by focusing on state and adding context about lifecycle interpretation.
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 advises polling scenario ('Use this to poll for transitions after submitting an input'), providing clear context. Does not mention when not to use or list alternatives, but guidance is specific and helpful.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the specific return contents (authored JSON, hosted record context), which is useful but does not contradict annotations. It adds moderate value beyond structured fields.
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 extraneous words, front-loading the key information about what the tool returns.
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 simple retrieval tool with one parameter, good annotations, and no output schema, the description adequately covers what is returned and the context needed. Sibling tools are addressed by implication.
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 parameter description. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and identifies the resource as 'a single agreement record' with key contents listed. It clearly distinguishes from siblings like get_agreement_document or get_agreement_state by specifying the full record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a single agreement record is needed by ID, but does not explicitly state when not to use it or mention alternatives. It provides clear context without exclusions.
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?
Adds context about returned statuses (PENDING, MINED, FAILED) beyond the annotations, which already declare readOnlyHint and idempotentHint. No contradictions.
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 states functionality, second states use case. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and does not describe the response structure (e.g., pagination format). Adequate for basic usage but could be more complete given 5 parameters and no output schema.
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 with descriptions, but the tool description adds value by summarizing that pagination and filtering by status are available, reinforcing the parameters' purposes.
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 returns recorded input submissions with pagination and filtering, distinguishing it from sibling tools like submit_input and get_agreement_state.
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 says to inspect events and their statuses, but does not mention when not to use it or provide alternative tool names for different use cases.
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?
Annotations already declare readOnlyHint and destructiveHint. The description adds that it reads the agreement record and signer nonce, and confirms no storage. This aligns with annotations and provides extra context. However, it omits authorization requirements (signer must be allowed by input definition), which could be useful for the agent.
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 three sentences, each serving a distinct purpose: stating the primary action, explaining the next steps, and noting side effects. It is front-loaded with the key purpose and contains no redundant 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 provides workflow context but lacks details on the return structure (typedData fields) and preconditions (e.g., agreement must be deployed, inputId must exist). Since there is no output schema, describing the return shape would improve completeness. The tool's complexity and 5 parameters warrant more guidance on prerequisites.
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 beyond the schema by noting the deadline defaults to one hour from now and contextualizing inputId and values relative to the agreement. This enhances understanding of how to use the parameters.
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 builds an EIP-712 payload for signing, linking it to submit_input. It distinguishes itself from siblings like submit_input (actual submission) and prepare_deployment_typed_data (deployment context) by specifying no transaction is sent. The verb 'builds' and resource 'EIP-712 payload' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines the intended workflow: prepare payload, sign, then call submit_input. It clarifies that no transaction is sent and nothing is stored, guiding safe usage. However, it does not explicitly state when not to use this tool or compare with alternatives like get_agreement, though the purpose implies it's only for preparing input permits.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety profile is known. Description adds that results are paginated, filterable, and sortable, and that only summaries are returned. No contradictions.
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, no wasted words. Front-loaded with the primary action and immediately clarifies what the tool returns. Every sentence adds essential 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 10 parameters and no output schema, the description covers the main capabilities (pagination, filtering, sorting, scope). Could be improved by noting that results are paginated via cursor, but it already mentions cursor and limit. Pointing to get_agreement for full details is helpful. Good overall.
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. Description adds value by grouping parameters into pagination, filtering, and sorting, and by mentioning that cursor and limit are for pagination, chain and state for filtering. This helps the agent understand how to combine parameters.
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?
States 'Lists agreement summaries visible to the current API key' with a specific verb and resource. Explicitly distinguishes from sibling 'get_agreement' by noting that this returns summaries only, while the sibling returns the full record.
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?
Clearly indicates when to use (for listing summaries) and explicitly references 'get_agreement' for full records. Does not provide explicit 'when not to use' scenarios but the context is clear enough.
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?
Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds context about advancing on-chain lifecycle and requiring permissions. However, it does not detail potential side effects beyond advancing lifecycle.
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 plus a scope note, front-loaded with main action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain return values or error handling. Given the complexity (8 parameters, nested objects), more detail on post-submission behavior would be beneficial.
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 covers 100% of parameters. Description adds context by linking parameters to agreement JSON and explaining the permit structure 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 the verb 'submit' and the resource 'signed input to a deployed agreement', and mentions advancing on-chain lifecycle. It distinguishes from sibling tools like prepare_input_typed_data by indicating it as a prerequisite.
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 conditions for use (input ID and values must match agreement JSON, signer must be allowed), provides alternative action (call prepare_input_typed_data), and specifies required scope (agreements.write).
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description is not burdened with basic safety. It adds behavioral context by explicitly listing what it does NOT validate and what it returns (warnings, keys, IDs), which goes beyond the annotations.
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 short and front-loaded with the main action. Every sentence serves a purpose, but some small improvements could be made (e.g., merging 'This does not validate...' and 'Iterate on...' more tightly). Overall efficient.
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 has one parameter, no output schema, rich annotations, and many siblings, the description covers its purpose, scope, return values, usage flow, and alternatives comprehensively. 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (agreement) already described in schema. The description adds value by explaining that the parameter is the authored agreement JSON and that the tool returns specific validation results, but does not detail the parameter's structure beyond what schema provides.
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 validates only the authored agreement JSON structure, distinct from deployment validation, and lists return fields (participant variable keys, input IDs, state IDs, warnings). It uses specific verb+resource and differentiates from sibling tool preflight_deployment.
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 (iterate on agreement JSON until no blocking warnings) and when not to use (for deployment values, wallets, signer, permit data) with a clear alternative (preflight_deployment). It also mentions required scope (agreements.write).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that 'no transaction is sent and nothing is stored,' which aligns with the annotations (readOnlyHint, idempotentHint). It also reveals that it 'reads the signer nonce from the target chain,' providing additional behavioral context beyond the 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 extremely concise with three sentences that convey purpose, usage instructions, and side-effect absence. Every sentence is informative and necessary, with no wasted 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 that there is no output schema, the description implicitly explains the return value by saying 'Sign the returned typedData.' It also covers critical details like reading the nonce. However, it could be slightly more explicit about the structure of the returned typedData object. Despite this, it is sufficiently complete for a data preparation tool with good annotations.
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 the schema already explains each parameter. The description adds value by tying parameters to the workflow (e.g., mentioning that 'deadline defaults to one hour from now' and that 'agreement' is the JSON to be deployed). However, the description does not introduce new parameter semantics beyond the schema, but it provides context that aids in understanding parameter relationships.
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 'builds the exact EIP-712 payload' for deployment authorization, using a specific verb and resource. It distinguishes itself from sibling tools like prepare_input_typed_data by focusing on deployment, and it explains the exact workflow (signing then calling deploy_agreement).
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 states when to use this tool (to prepare the payload for signing before calling deploy_agreement) and provides step-by-step instructions for the next actions (signing and calling deploy_agreement with specific components). It also implies not to use this tool if you want to directly deploy without preparing typed data.
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:

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

Score Badge

Copy to your README.md:

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

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/CNSLabs/agreements-api-sdk'

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