Ask your agent for the right contract.

You are an API contract engineer. Analyze the API source code, route definitions, validation schemas, data models, authentication middleware, and requirements I provide.

Create a complete OpenAPI 3.1.0 contract as valid JSON for this API.

Requirements:
1. Return JSON only. Do not wrap it in Markdown or add commentary.
2. Include openapi, info, servers, paths, components.schemas, and components.securitySchemes where applicable.
3. Give every operation a unique, stable operationId suitable for use as an AI tool name.
4. Add a concise summary and a precise description explaining when the operation should be used and any important side effects.
5. Model all path, query, header, and cookie parameters with correct required flags and schemas.
6. Model request bodies, content types, required properties, enums, formats, nullable values, arrays, and nested objects accurately.
7. Document meaningful success and error responses without inventing behavior not present in the source.
8. Model Bearer, Basic, API-key, OAuth, or OpenID authentication based only on the implementation I provide.
9. Use reusable component schemas and local $ref references. Do not use external $ref URLs.
10. Include the real API base URL if I provide it; otherwise use "https://api.example.com" and clearly identify it as a placeholder in the server description.
11. Do not include real credentials, tokens, passwords, customer records, or secret environment values.
12. Do not invent endpoints. If required information is missing, ask me focused questions before generating the final JSON.

Before returning the contract, internally verify that the JSON parses, every path parameter exists in its path template, operationIds are unique, referenced schemas exist, and each request body matches the implementation.

API context begins below:
[PASTE OR ATTACH ROUTES, CONTROLLERS, SCHEMAS, DOCUMENTATION, OR REQUIREMENTS]

You are preparing one REST API request for import into AlltoMCP.

Based on the endpoint documentation, source code, or requirements I provide, produce one complete cURL command.

Requirements:
1. Return only the cURL command. Do not add Markdown fences or explanation.
2. Start with curl and include a complete HTTP or HTTPS URL.
3. Include the explicit HTTP method with -X when the operation is not a simple GET.
4. Include all required query parameters using safe example values.
5. Include Content-Type and any other structurally required headers.
6. For JSON requests, include a valid representative JSON body using --data-raw.
7. Use placeholders such as YOUR_BEARER_TOKEN, YOUR_API_KEY, and resource_123. Never include real secrets or personal data.
8. Use "Authorization: Bearer YOUR_BEARER_TOKEN" for bearer authentication, -u "USERNAME:PASSWORD" for Basic authentication, or the documented API-key header.
9. Preserve required path parameters with safe example values so AlltoMCP can infer the request shape.
10. Do not add unsupported cURL flags, shell substitutions, environment expansion, output files, or executable shell logic.
11. Do not invent request fields. Ask me focused questions if the method, URL, authentication, or body is unclear.

Endpoint context begins below:
[PASTE THE ENDPOINT DOCUMENTATION, ROUTE CODE, OR REQUEST REQUIREMENTS]

You are an API integration engineer. Analyze the REST API routes, controllers, request validators, authentication, and requirements I provide.

Create a valid Postman Collection v2.1 JSON document that can be uploaded to AlltoMCP.

Requirements:
1. Return JSON only. Do not wrap it in Markdown or add commentary.
2. Use the official Postman Collection v2.1 schema URL in info.schema.
3. Give the collection a clear name and useful description.
4. Define a collection variable named baseUrl and use {{baseUrl}} in every request URL.
5. Keep all requests on one API host. If the source uses multiple hosts, ask me which host to export or recommend separate collections.
6. Group related requests into descriptive folders.
7. Give every request a clear name and a precise description, including side effects for create, update, delete, payment, notification, or other write operations.
8. Include correct methods, paths, query parameters, required headers, content types, and representative request bodies.
9. Configure collection-level Bearer, Basic, or API-key authentication when the API uses one shared scheme.
10. Use placeholders such as YOUR_BEARER_TOKEN and YOUR_API_KEY. Never include real credentials, cookies, customer data, or environment secrets.
11. Use valid JSON bodies and safe representative values that show the expected shape.
12. Do not include test scripts, pre-request scripts, shell code, or requests not supported by the source.
13. Do not invent endpoints or fields. Ask focused questions before generating the final JSON if essential information is missing.

Before returning the collection, internally verify that the JSON parses, every request resolves from baseUrl, names are unique, bodies match their content types, and no credential values are present.

API context begins below:
[PASTE OR ATTACH ROUTES, CONTROLLERS, SCHEMAS, DOCUMENTATION, OR REQUIREMENTS]

You are preparing a GraphQL schema for import into AlltoMCP.

Obtain a standard GraphQL introspection result from the GraphQL server or project I provide and save it as valid JSON with this top-level shape: {"data":{"__schema":{...}}}.

Requirements:
1. Use the standard complete GraphQL introspection query against the actual schema. Prefer the project framework's schema/introspection tooling when available.
2. Return or save JSON only. Do not convert the schema to SDL, JSON Schema, OpenAPI, or a custom format.
3. Preserve queryType, mutationType, subscriptionType, types, fields, arguments, inputFields, enumValues, possibleTypes, descriptions, deprecation flags, and nested type references.
4. Include NON_NULL and LIST wrappers exactly as reported by introspection.
5. Do not fabricate introspection data from incomplete documentation. If the endpoint disables introspection, inspect the server schema directly or ask me for the GraphQL SDL/source.
6. Do not include authorization tokens, headers, cookies, environment variables, response data, or resolver secrets in the output file.
7. If authentication is required to run introspection, use credentials only at request time and never write them into the JSON.
8. Verify that the final JSON parses and that data.__schema.types is a non-empty array.

Save the final artifact as graphql-schema.json and tell me its path. Do not summarize or rewrite the schema.

GraphQL project or endpoint context begins below:
[ATTACH THE PROJECT OR PROVIDE THE GRAPHQL ENDPOINT, SDL, AND SAFE ACCESS INSTRUCTIONS]

You are designing one safe GraphQL operation to expose as an MCP tool in AlltoMCP.

Using the GraphQL schema and workflow I provide, produce the following four labeled outputs:
TOOL_NAME
DESCRIPTION
GRAPHQL_DOCUMENT
VARIABLES_JSON_SCHEMA

Requirements:
1. TOOL_NAME must be a stable snake_case identifier using only letters, numbers, and underscores.
2. DESCRIPTION must explain exactly when the tool should be used, required identifiers, important constraints, and any side effects.
3. GRAPHQL_DOCUMENT must be one named query or mutation with explicit variables and a minimal useful selection set.
4. VARIABLES_JSON_SCHEMA must be valid JSON Schema with type "object", properties for every GraphQL variable, required fields matching non-null variables, and additionalProperties set to false.
5. Map ID and String to string, Int to integer, Float to number, Boolean to boolean, lists to arrays, enums to enum values, and input objects to nested object schemas.
6. Do not hard-code identifiers, credentials, personal data, or production values in the GraphQL document.
7. Do not expose broad or destructive mutations unless the requested workflow requires them. State irreversible effects explicitly.
8. Do not invent fields or arguments. Ask focused questions if the supplied schema is insufficient.
9. Validate the operation against the supplied schema before returning it.

GraphQL schema and intended workflow begin below:
[PASTE THE RELEVANT GRAPHQL SDL OR INTROSPECTION TYPES AND DESCRIBE THE TOOL WORKFLOW]